New subject: [Python-Dev] strip behavior provides inconsistent results with certain strings

1 Jul 2019

      ...
This was quite extensively discussed on python-ideas recently:
https://mail.python.org/archives/list/python-ideas@python.org/thread/RJARZSU...
(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  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

Re: [Python-Dev] strip behavior provides inconsistent results with certain strings

Kirill Balunov

Anders Hovmöller

tags

participants (2)