Ivan Pozdeez wrote: > I must note that names conforming to https://www.python.org/dev/peps/pep-0008/#function-and-variable-names would be "strip_prefix" and "strip_suffix".
In this case, being in line with the existing string API method names take priority over PEP 8, e.g. splitlines, startswith, endswith, splitlines, etc. Although I agree that an underscore would probably be a bit easier to read here, it would be rather confusing to randomly swap between the naming convention for the same API. The benefit gained in *slightly *easier readability wouldn't make up for the headache IMO. On Sun, Mar 22, 2020 at 12:13 AM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > On 22.03.2020 6:38, Guido van Rossum wrote: > > On Sat, Mar 21, 2020 at 6:46 PM Nick Coghlan <ncogh...@gmail.com> wrote: > >> On Sat., 21 Mar. 2020, 11:19 am Nathaniel Smith, <n...@pobox.com> wrote: >> >>> On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney >>> <sweeney.dennis...@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.) > > I must note that names conforming to > https://www.python.org/dev/peps/pep-0008/#function-and-variable-names > would be "strip_prefix" and "strip_suffix". > > > >> 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. >> > > -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him **(why is my pronoun here?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> > > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to > python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/Q33NGX3N4JEI3ECUW3WBL33EX2JR3Y5C/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > Regards, > Ivan > > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@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/WW4V6S7BSBOP2VU4OCLGANMPVQYY7A4O/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/TB5UXJR77SEDDGQHFXCJO4AIU6LJ3VCI/ Code of Conduct: http://python.org/psf/codeofconduct/
