On Sat., 21 Mar. 2020, 11:19 am Nathaniel Smith, <
njs@pobox.com> wrote:
On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
<sweeney.dennis650@gmail.com> wrote:
> This is a proposal to add two new methods, ``cutprefix`` and
> ``cutsuffix``, to the APIs of Python's various string objects.
The names should use "start" and "end" instead of "prefix" and
"suffix", to reduce the jargon factor and for consistency with
startswith/endswith.
This would also be more consistent with startswith() & endswith(). (For folks querying this: the relevant domain here is "str builtin method names", and we already use startswith/endswith there, not hasprefix/hassuffix. The most challenging relevant audience for new str builtin method *names* is also 10 year olds learning to program in school, not adults reading the documentation)
To my language sense, hasprefix/hassuffix are horrible compared to startswith/endswith. If you were to talk about this kind of condition using English instead of Python, you wouldn't say "if x has prefix y", you'd say "if x starts with y". (I doubt any programming language uses hasPrefix or has_prefix for this, making it a strawman.)
*But*, what would you say if you wanted to express the idea or removing something from the start or end? It's pretty verbose to say "remove y from the end of x", and it's not easy to translate that into a method name. x.removefromend(y)? Blech! And x.removeend(y) has the double 'e', which confuses the reader.
The thing is that it's hard to translate "starts" (a verb) into a noun -- the "start" of something is its very beginning (i.e., in Python, position zero), while a "prefix" is a noun that specifically describes an initial substring (and I'm glad we don't have to use *that* :-).
I think the concern about stripstart() & stripend() working with substrings, while strip/lstrip/rstrip work with character sets, is valid, but I also share the concern about introducing "cut" as yet another verb to learn in the already wide string API.
It's not great, and I actually think that "stripprefix" and "stripsuffix" are reasonable. (I found that in Go, everything we call "strip" is called "Trim", and there are "TrimPrefix" and "TrimSuffix" functions that correspond to the PEP 616 functions.)
The example where the new function was used instead of a questionable use of replace gave me an idea, though: what if the new functions were "replacestart()" and "replaceend()"?
* uses "start" and "with" for consistency with the existing checks
* substring based, like the "replace" method
* can be combined with an extension of "replace()" to also accept a tuple of old values to match and replace to allow for consistency with checking for multiple prefixes or suffixes.
We'd expect the most common case to be the empty string, but I think the meaning of the following is clear, and consistent with the current practice of using replace() to delete text from anywhere within the string:
s = s.replacestart('context.' , '')
This feels like a hypergeneralization. In 99.9% of use cases we just need to remove the prefix or suffix. If you want to replace the suffix with something else, you can probably use string concatenation. (In the one use case I can think of, changing "foo.c" into "foo.o", it would make sense that plain "foo" ended up becoming "foo.o", so s.stripsuffix(".c") + ".o" actually works better there.
This approach would also very cleanly handle the last example from the PEP:
s = s.replaceend(('Mixin', 'Tests', 'Test'), '')
Maybe the proposed functions can optionally take a tuple of prefixes/suffixes, like startswith/endswith do?
The doubled 'e' in 'replaceend' isn't ideal, but if we went this way, I think keeping consistency with other str method names would be preferable to adding an underscore to the name.
Agreed on the second part, I just really don't like the 'ee'.
Interestingly, you could also use this to match multiple prefixes or suffixes and find out *which one* matched (since the existing methods don't report that):
s2 = s.replaceend(suffixes, '')
suffix_len = len(s) - len(s2)
suffix = s[-suffix-len:] if suffix_len else None
Cheers,
Nick.