This was quite extensively discussed on python-ideas recently:
(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
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