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