Nice PEP! That this discussion wound up in the NP-complete "naming things" territory as the main topic right from the start/prefix/beginning speaks highly of it. :)
The only things left I have to add are (a) agreed on don't specify if it is a copy or not for str and bytes.. BUT (b) do specify that for bytearray. Being the only mutable type, it matters. Consistency with other bytearray methods based on https://docs.python.org/3/library/stdtypes.html#bytearray suggests copy. (Someone always wants inplace versions of bytearray methods, that is a separate topic not for this pep) Fwiw I *like* your cutprefix/suffix names. Avoiding the terms strip and trim is wise to avoid confusion and having the name read as nice English is Pythonic. I'm not going to vote on other suggestions. -gps On Sat, Mar 21, 2020, 9:32 PM Kyle Stanley <aeros...@gmail.com> wrote: > > 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. > > Oops, I just realized that I wrote "splitlines" twice there. I guess that > goes to show how much I use that specific method in comparison to the > others, but the point still stands. Here's a more comprehensive set of > existing string methods to better demonstrate it (Python 3.8.2): > > >>> [m for m in dir(str) if not m.startswith('_')] > ['capitalize', 'casefold', 'center', 'count', 'encode', 'endswith', > 'expandtabs', 'find', 'format', 'format_map', 'index', 'isalnum', > 'isalpha', 'isascii', 'isdecimal', 'isdigit', 'isidentifier', 'islower', > 'isnumeric', 'isprintable', 'isspace', 'istitle', 'isupper', 'join', > 'ljust', 'lower', 'lstrip', 'maketrans', 'partition', 'replace', 'rfind', > 'rindex', 'rjust', 'rpartition', 'rsplit', 'rstrip', 'split', 'splitlines', > 'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill'] > > On Sun, Mar 22, 2020 at 12:17 AM Kyle Stanley <aeros...@gmail.com> wrote: > >> 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/O44UVEJCDAT46L54U2NUVLXYAT6TAM4T/ > 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/EJH45R3QYNUFPFFAPXE2QB5YSFWVITER/ Code of Conduct: http://python.org/psf/codeofconduct/
