I'm a big +1. I prefer strip_prefix/strip_suffix but only by a little bit.
> On 1 Jul 2019, at 21:34, Kirill Balunov <kirillbalu...@gmail.com> wrote: > >> This was quite extensively discussed on python-ideas recently: >> >> https://mail.python.org/archives/list/python-ideas@python.org/thread/RJARZSUKCXRJIP42Z2YBBAEN5XA7KEC3/#WIRID57ESUFUAQQQ6ZUY2RK5PKQQYSJ3 >> >> (I'm finding it hard to find a good thread view in the new interface -- but >> that will get you started) >> >> My memory of that thread is that there was a lot of bike shedding, and quite >> a lot of resistance to adding a couple new methods, which I personally never >> understood (Not why we don't want to add methods willy-nilly, but why there >> was this much resistance to what seems like an low-disruption, low >> maintenance, and helpful addition) >> >> I think it just kind of petered out, rather than being rejected, so if >> someone wants to take up the mantle, that would be great -- and some support >> from a core dev or two would probably help. >> >> -CHB >> >> >> >> >>> On Fri, Jun 28, 2019 at 10:44 AM Brett Cannon <br...@python.org> wrote: >>> Glenn Linderman wrote: >>> > On 6/27/2019 3:09 PM, Brett Cannon wrote: >>> > > My guess is that without Guido to just ask this will >>> > > have to go to a PEP as it changes a built-in. >>> > > How does adding two new methods change a built-in? >>> > > Now if an extra parameter were added to modify lstrip, rstrip, and >>> > > strip >>> > to make them do something different, yes. >>> > But adding new methods doesn't change anything, unless someone is >>> > checking for their existence. >>> >>> Sure, but the built-ins are so widely used that we don't want to blindly >>> add every method idea that someone comes up with either. We all very much >>> share ownership of the built-ins, so we should all agree to changes to >>> them, and getting agreement means either clear consensus and/or a PEP. >>> >>> -Brett >>> >>> > My preferred color is pstrip and sstrip (prefix and suffix strip) since >>> > lstrip and rstrip mean left and right. >>> > And maybe there should be a psstrip, that takes two parameters, the >>> > prefix and the suffix to strip. >>> > Such functions would certainly reduce code in a lot of places where I do >>> > if string.startswith('foo'): >>> > string = string[ 3: ]; >>> > as well as making it more robust, because the string and its length have >>> > to stay synchronized when changes are made. > > I think this type of discussion better fits here. Quickly looking through > the aforementioned branch - I want to say that that branch died due to > bike-shedding :) > > I'm sure this has already been proposed, but it seems to me that the most > natural would be to expand the functionality of existing `.lstrip`, `.rstrip` > and maybe `.strip` methods. Probably many do not like what _names_ were given > to these methods. But nothing can be done about it, they are what they are > and will not go anywhere. Adding two more methods with similar functionality > will only confuse. Moreover since we already have a precedent with other > string methods like `.startswith` and `.endswith` that accepts as an > argument both a string and a tuple of strings. > > On the other hand, this suggests that this functionality makes sense only for > `.lstrip` and `.rstrip` variants. Is such a discrepancy acceptable? > > If it is, I will suggest to allow `.lstrip` and `.rstrip` to accept tuple of > strings. The _stripping_ will be carried out in accordance with the linear > probing and only one stripping at a time. > > >>> s = 'paparazzi' > >>> s.lstrip(('pa', 'ra')) > 'parazzi' > > Which also deviates from the existing semantics of strinst.split(strinst). Is > this also permissible? > > Perhaps all these discrepancies lead to the idea of having new names for > these methods. But for me personally, all these deviations are an inevitable > price for practicality and, of course, echoes of past decisions. > > I would like to have such a functionality and find it usedul. Just today, I > needed to remove the “model_” substring from beginnings of the set of file > filenames, but this does not work because some of the files have names, like > "model_ma...", "model_me...", "model_or..." and so on. > > with kind regards, > -gdg > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/XYFQMFPUV6FR2N5BGYWPBVMZ5BE5PJ6C/ > Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RJIRFKJNFPM7BGJBTGUKBIOYTHPBTR6Z/ Code of Conduct: http://python.org/psf/codeofconduct/
