On Fri, Jun 28, 2019 at 01:08:45AM +1000, Chris Angelico wrote:

Help on built-in function lstrip: [...] This does NOT remove a leading substring. It removes a set of characters.

This is a re-occurring painpoint and gotcha. I've fallen for it myself. I really think it's long past time we bite the bullet and add a pair of methods to strip a prefix and suffix from strings. My preferred bikeshed colour would be strip_prefix and strip_suffix. Will this need a PEP? -- Steven

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. 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.

On 6/28/2019 10:10 AM, MRAB wrote:

On 2019-06-28 03:40, 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.

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.

lstrip and rstrip remove treat the argument as a set of characters and can remove multiple characters, so having additional methods pstrip and sstrip with their very similar names but different behaviours could be confusing.

I'd prefer to stick with lXXX and rXXX. ldrop and rdrop, maybe?

I was thinking of the change from stripping sets of characters versus stripping specific sequences of characters, all being strip operations. But when you point out the confusion and suggest the change of names, I got to thinking about names, and really, the   pstrip/ldrop or sstring/rdrop  operations are more like  "replace" than "strip"... there has to be an exact match. So maybe a better solution to the functionality needed would be lreplace and rreplace.  On the other hand,  the existing   .replace( prefix, '', 1 )  almost implements lreplace! It doesn't require it to be a prefix though :(  And there is no option for doing the last N replacements, nor requiring a single one to be a suffix.  The last N replacements could be done by using a negative N, but it would seem an additional parameter or new name would be required to do prefix- and suffix-restricted operations. So my example above could be written as either: string.lreplace('foo') string.lreplace('foo', '') But calling the operations lreplace and rreplace, including the option of putting in replacement strings, would actually be quite handy.  Think of this: filename.rreplace('.html', '.css', True ) where the first parameter is the suffix to remove, the second parameter is a suffix to replace it with, and the third parameter says to add the replacement even if the first parameter is not found/removed.  That's another operation I find frequently in batch file processing, that otherwise takes several lines. As Ned noted in another branch of this discussion, it would be good to have an update for the 2.7 documentation.  And if new functions are added, by any name, it would be good to have the 3.x documentation clearly reference in both directions between lstrip and lreplace, and between rstrip and rreplace (or whatever names).

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.

---

Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SB6JECL6...

-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

On 7/1/2019 8:28 PM, Terry Reedy wrote:

On 7/1/2019 1:57 PM, Chris Barker via Python-Dev wrote:

...

This was quite extensively discussed on python-ideas recently:

https://mail.python.org/archives/list/python-ideas@python.org/thread/RJARZSU...

The claim of 'inconsistent results' is based on not reading the doc.

...

(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 did not read much of the thread, but the proposal is to wrap a near-trivial expression (2 operations) or replace a current method call with a method call than is more or less the same len as what it replaces.

...

...

...

'prefix_more_suffix'[len('prefix'):]  # if know s begins with p '_more_suffix'

...

...

...

'prefix_more_suffix'.replace('prefix', '') '_more_suffix'

...

...

...

'prefix_more_suffix'.strip_pre('prefix')  # proposed

Your example isn't equivalent: .replace would replace multiple instances of prefix, not necessarily at the beginning. The .strip_pre (however spelled) would strip one instance, only if it is at the beginning. The more I thought about this, the more I think a more functional goal is a variation of replace that works only on one end or the other, rather than a variation of strip. I outlined that in a different branch in this thread. The other documentation issue I noticed is that the 2nd and 3rd parameters to startswith and endswith are not fully documented. Typically startswith and endswitch are in the logic prior to the strip/replace operation, and typically only use the first parameter, but looking at their documentation as part of this discussion, I found it lacking.

A method could raise instead of returning the string as-is if the prefix is not really a prefix.  How often is this needed?  The most common end deletions are whitespace, which the current .strip handles correctly.

raising wouldn't be helpful in most of the situations where I use this logic... it would require a more complex flow control than the if startswith path in the current situation. Yes, I use strip more frequently, but if startswith: chop_prefix operation (and the other end too) happens an awful lot.

It seems to me that the desired behavior here is closest to 'str.replace()' out of all the options discussed, just with the constraint of being limited to either the start or the end of the string. (Thus the .lreplace() and .rreplace() option suggested by Glenn.) The minimal change (which actually also is pretty general?) I think would be to add 'only_start' and 'only_end' keyword arguments to str.replace(), both defaulting to False. If, e.g., 'only_start' is passed True, each repetition of 'old' at the start of 's' is replaced by 'new', with the number of replacements limited by the existing optional 'count'. Similar behavior for 'only_end'=True. Probably best to raise a ValueError(?) if both 'only_start'=True and 'only_end'=True? Taking swapping a file extension as an example of a particular transformation of interest, it would be achieved with something like s.replace(".htm", ".html", only_end=True). -Brian

On Tue, Jul 2, 2019 at 4:24 PM wrote:

It seems to me that the desired behavior here is closest to 'str.replace()' out of all the options discussed, just with the constraint of being limited to either the start or the end of the string. (Thus the .lreplace() and .rreplace() option suggested by Glenn.)

The minimal change (which actually also is pretty general?) I think would be to add 'only_start' and 'only_end' keyword arguments to str.replace(), both defaulting to False. If, e.g., 'only_start' is passed True, each repetition of 'old' at the start of 's' is replaced by 'new', with the number of replacements limited by the existing optional 'count'. Similar behavior for 'only_end'=True. Probably best to raise a ValueError(?) if both 'only_start'=True and 'only_end'=True?

Taking swapping a file extension as an example of a particular transformation of interest, it would be achieved with something like s.replace(".htm", ".html", only_end=True).

-Brian

Just to add my own touch of colour to the bike shed, I'd suggest that more naturally-usable names for those arguments, should they be added, would be at_start and at_end. regards Steve

On 7/2/2019 12:56 PM, Terry Reedy wrote:

On 7/2/2019 12:16 AM, Glenn Linderman wrote:

...

On 7/1/2019 8:28 PM, Terry Reedy wrote:

...

...

I did not read much of the thread, but the proposal is to wrap a near-trivial expression (2 operations) or replace a current method call with a method call than is more or less the same len as what it replaces.

...

...

...

'prefix_more_suffix'[len('prefix'):]  # if know s begins with p '_more_suffix'

...

...

...

'prefix_more_suffix'.replace('prefix', '') '_more_suffix'

...

...

...

'prefix_more_suffix'.strip_pre('prefix')  # proposed

Your example isn't equivalent: .replace would replace multiple instances of prefix, not necessarily at the beginning. The .strip_pre (however spelled) would strip one instance, only if it is at the beginning.

I left out the slightly longer regex which does exactly that.

...

...

...

re.sub('^prefix', '', 'prefix_more_suffix') '_more_suffix' re.sub('^prefix', '', 'Xprefix_more_suffix') 'Xprefix_more_suffix'

or with minor variation, deletes only suffixes.

...

...

...

re.sub('suffix$', '', 'prefix_more_suffix') 'prefix_more_'

Are these special cases, which can be easily generalized to match more than one string, and to replace rather than delete, special enough to merit a new method each.  This remains to be demonstrated.

...

The more I thought about this, the more I think a more functional goal is a variation of replace that works only on one end or the other, rather than a variation of strip. I outlined that in a different branch in this thread.

To me, a new parameter to str.replace would have a lower bar to acceptance.

two extra boolean parameters has been suggested; alternatives would be a single string or flag parameter. replace already accepts a count parameter for maximum number of replacements from the start. One could extend that to pass a negative count parameter to mean how many from the end, which is similar to negative indexing for slices, which wouldn't even need an extra parameter, but also wouldn't restrict it to the exact front or end.  Together with one extra boolean to declare the replacement must be at the very front (for positive count) or very end (for negative count), would also allow removal of repeated prefixes or suffixes, although I'm not sure that would be a common case: text = 'Hello Hello Hello Is this Fred?' text.replace('Hello ', '', 2, True ) would leave one Hello. Of course it wouldn't have that effect with a non-empty replacement: text.replace('Hello ', 'Greetings', 2, True ) would leave two Hello.

...

The other documentation issue I noticed is that the 2nd and 3rd parameters to startswith and endswith are not fully documented. Typically startswith and endswitch are in the logic prior to the strip/replace operation, and typically only use the first parameter, but looking at their documentation as part of this discussion, I found it lacking.

File an issue?  Preferably with a suggested change.

To suggest a change, I'd first have run lots of experiments to figure out what they do... and what the edge conditions are... or, I'd have to read the implementation to figure it out. I've never used anything but the first parameter and reading the documentation for the other two raises more questions than it answers.  But I'll open the issue, maybe someone can quickly answer the questions I raise, but the terseness of the description of the parameters leaves a lot of room for speculation. https://bugs.python.org/issue37490

excellent and extraordinarily obvious Thanks for the pointer. a bit unfortunate that old docs for a module that doesn't seem to exist in py3 with less clear but still correct words is still the top google result for python string strip. https://docs.python.org/2/library/string.html#string.lstrip string.lstrip(s[, chars])¶ Return a copy of the string with leading characters removed. If chars is omitted or None, whitespace characters are removed. If given and not None, chars must be a string; the characters in the string will be stripped from the beginning of the string this method is called on.

On Jun 27, 2019, at 15:27, Jelle Zijlstra wrote:

El jue., 27 jun. 2019 a las 11:51, escribió:

...

excellent and extraordinarily obvious

Thanks for the pointer.

a bit unfortunate that old docs for a module that doesn't seem to exist in py3 with less clear but still correct words is still the top google result for python string strip.

https://docs.python.org/2/library/string.html#string.lstrip

string.lstrip(s[, chars])¶

Return a copy of the string with leading characters removed. If chars is omitted or None, whitespace characters are removed. If given and not None, chars must be a string; the characters in the string will be stripped from the beginning of the string this method is called on. That function actually also behaves like str.lstrip() does in Python 3:

...

...

...

string.lstrip('abcd', 'ba') 'cd'

I think this is just a minor documentation issue, i.e. no need to change any behavior. The issue is that, in Python 2, there are the strip string methods as in Python 3 but there are also the old deprecated string.strip functions from the string module. As Jelle points out, the py2 string function form of strip behaves like the string method versions of strip behave in both py2 and py3. At some point the documentation for the strip string methods was changed to include this: "The chars argument is not a prefix or suffix; rather, all combinations of its values are stripped." https://docs.python.org/2/library/stdtypes.html#str.strip But the docs for the 2.7 string function were not so updated. Likewise for lstrip and rstrip. So if someone were motivated to create a 2.7 doc PR to update the wording for the three string module functions, that should lessen any confusion. -- Ned Deily nad@python.org -- []