iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add references to past discussion threads, fix formatting and typos (#1335)

This commit is contained in:
sweeneyde 2020-03-22 17:16:57 -04:00 committed by GitHub
parent 0093a853e8
commit 9c16d3539e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 55 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

100
pep-0616.rst
View File

@ -23,14 +23,15 @@ if present, and would be added to to Unicode ``str`` objects, binary
Rationale Rationale
========= =========
There have been repeated issues [#confusion]_ on the Bug Tracker There have been repeated issues on Python-Ideas [#pyid]_ [3]_,
and StackOverflow related to user confusion about the existing Python-Dev [4]_ [5]_ [6]_ [7]_, the Bug Tracker, and
``str.lstrip`` and ``str.rstrip`` methods. These users are typically StackOverflow [#confusion]_, related to user confusion about the
expecting the behavior of ``cutprefix`` and ``cutsuffix``, but they existing ``str.lstrip`` and ``str.rstrip`` methods. These users are
are surprised that the parameter for ``lstrip`` is interpreted as a typically expecting the behavior of ``cutprefix`` and ``cutsuffix``,
set of characters, not a substring. This repeated issue is evidence but they are surprised that the parameter for ``lstrip`` is
that these methods are useful, and the new methods allow a cleaner interpreted as a set of characters, not a substring. This repeated
redirection of users to the desired behavior. issue is evidence that these methods are useful. The new methods
allow a cleaner redirection of users to the desired behavior.
As another testimonial for the usefulness of these methods, several As another testimonial for the usefulness of these methods, several
users on Python-Ideas [#pyid]_ reported frequently including similar users on Python-Ideas [#pyid]_ reported frequently including similar
@ -105,19 +106,19 @@ Methods with the corresponding semantics will be added to the builtin
``bytes`` and ``bytearray`` objects. If ``b`` is either a ``bytes`` ``bytes`` and ``bytearray`` objects. If ``b`` is either a ``bytes``
or ``bytearray`` object, then ``b.cutsuffix()`` and ``b.cutprefix()`` or ``bytearray`` object, then ``b.cutsuffix()`` and ``b.cutprefix()``
will accept any bytes-like object or tuple of bytes-like objects as an will accept any bytes-like object or tuple of bytes-like objects as an
argument. The one-at-a-time checking of types matches the implementation argument. The one-at-a-time checking of types matches the implementation
of ``startswith()`` and ``endswith()`` methods. of ``startswith()`` and ``endswith()`` methods.
The ``self_str[:]`` copying behavior in the code ensures that the The ``self_str[:]`` copying behavior in the code ensures that the
``bytearray`` methods do not return ``self``, but it does not preclude ``bytearray`` methods do not return ``self``, but it does not preclude
the ``str`` and ``bytes`` methods from returning ``self``. Because the ``str`` and ``bytes`` methods from returning ``self``. Because
``str`` and ``bytes`` instances are immutable, the ``cutprefix()`` ``str`` and ``bytes`` instances are immutable, the ``cutprefix()``
and ``cutsuffix()`` methods on these objects methods may (but are not and ``cutsuffix()`` methods on these objects may (but are not
required to) make the optimization of returning ``self`` if required to) make the optimization of returning ``self`` if
``type(self) is str`` (``type(self) is bytes`` respectively) ``type(self) is str`` (``type(self) is bytes`` respectively)
and the given affixes are not found, or are empty. As such, following and the given affixes are not found, or are empty. As such, the
behavior is considered a CPython implementation detail, and is not following behavior is considered a CPython implementation detail, and
guaranteed by this specification:: is not guaranteed by this specification::
>>> x = 'foobar' * 10**6 >>> x = 'foobar' * 10**6
>>> x.cutprefix('baz') is x is x.cutsuffix('baz') >>> x.cutprefix('baz') is x is x.cutsuffix('baz')
@ -127,7 +128,7 @@ guaranteed by this specification::
To test whether any affixes were removed during the call, users To test whether any affixes were removed during the call, users
should use the constant-time behavior of comparing the lengths of should use the constant-time behavior of comparing the lengths of
original and new strings:: the original and new strings::
>>> string = 'Python String Input' >>> string = 'Python String Input'
>>> new_string = string.cutprefix("Py") >>> new_string = string.cutprefix("Py")
@ -149,19 +150,18 @@ one or more of the following:
1. Less fragile: 1. Less fragile:
- The code will not depend on the user to count the length of a The code will not depend on the user to count the length of a literal.
literal.
2. More performant: 2. More performant:
- The code does not require a call to the Python built-in The code does not require a call to the Python built-in ``len``
``len`` function, nor to the more expensive ``str.replace`` function, nor to the more expensive ``str.replace()``
function. method.
3. More descriptive: 3. More descriptive:
- The methods give a higher-level API for code readability, as The methods give a higher-level API for code readability, as
opposed to the traditional method of string slicing. opposed to the traditional method of string slicing.
find_recursionlimit.py find_recursionlimit.py
@ -305,45 +305,45 @@ Several alternatives method names have been proposed. Some are listed
below, along with commentary for why they should be rejected in favor below, along with commentary for why they should be rejected in favor
of ``cutprefix`` (the same arguments hold for ``cutsuffix``). of ``cutprefix`` (the same arguments hold for ``cutsuffix``).
- ``ltrim`` - ``ltrim``, ``trimprefix``, etc.:
- "Trim" does in other languages (e.g. JavaScript, Java, Go, "Trim" does in other languages (e.g. JavaScript, Java, Go, PHP)
PHP) what ``strip`` methods do in Python. what ``strip`` methods do in Python.
- ``lstrip(string=...)`` - ``lstrip(string=...)``
- This would avoid adding a new method, but for different This would avoid adding a new method, but for different
behavior, it's better to have two different methods than one behavior, it's better to have two different methods than one
method with a keyword argument that select the behavior. method with a keyword argument that select the behavior.
- ``cut_prefix`` - ``cut_prefix``:
- All of the other methods of the string API, e.g. All of the other methods of the string API, e.g.
``str.startswith()``, use ``lowercase`` rather than ``str.startswith()``, use ``lowercase`` rather than
``lower_case_with_underscores``. ``lower_case_with_underscores``.
- ``cutleft``, ``leftcut``, or ``lcut`` - ``cutleft``, ``leftcut``, or ``lcut``:
- The explicitness of "prefix" is preferred. The explicitness of "prefix" is preferred.
- ``removeprefix``, ``deleteprefix``, ``withoutprefix``, ``dropprefix``, etc. - ``removeprefix``, ``deleteprefix``, ``withoutprefix``, ``dropprefix``, etc.:
- All of these might have been acceptable, but they have more All of these might have been acceptable, but they have more
characters than ``cut``. Some suggested that the verb "cut" characters than ``cut``. Some suggested that the verb "cut"
implies mutability, but the string API already contains verbs implies mutability, but the string API already contains verbs
like "replace", "strip", "split", and "swapcase". like "replace", "strip", "split", and "swapcase".
- ``stripprefix`` - ``stripprefix``:
- Users may benefit from remembering that "strip" means working Users may benefit from remembering that "strip" means working
with sets of characters, while other methods work with with sets of characters, while other methods work with
substrings, so re-using "strip" here should be avoided. substrings, so re-using "strip" here should be avoided.
Reference Implementation Reference Implementation
======================== ========================
See the pull request on GitHub [#pr]_. See the pull request on GitHub [#pr]_ (not updated).
References References
@ -351,8 +351,18 @@ References
.. [#pr] GitHub pull request with implementation .. [#pr] GitHub pull request with implementation
(https://github.com/python/cpython/pull/18939) (https://github.com/python/cpython/pull/18939)
.. [#pyid] Discussion on Python-Ideas .. [#pyid] [Python-Ideas] "New explicit methods to trim strings"
(https://mail.python.org/archives/list/python-ideas@python.org/thread/RJARZSUKCXRJIP42Z2YBBAEN5XA7KEC3/) (https://mail.python.org/archives/list/python-ideas@python.org/thread/RJARZSUKCXRJIP42Z2YBBAEN5XA7KEC3/)
.. [3] "Re: [Python-ideas] adding a trim convenience function"
(https://mail.python.org/archives/list/python-ideas@python.org/thread/SJ7CKPZSKB5RWT7H3YNXOJUQ7QLD2R3X/#C2W5T7RCFSHU5XI72HG53A6R3J3SN4MV)
.. [4] "Re: [Python-Dev] strip behavior provides inconsistent results with certain strings"
(https://mail.python.org/archives/list/python-ideas@python.org/thread/XYFQMFPUV6FR2N5BGYWPBVMZ5BE5PJ6C/#XYFQMFPUV6FR2N5BGYWPBVMZ5BE5PJ6C)
.. [5] [Python-Dev] "correction of a bug"
(https://mail.python.org/archives/list/python-dev@python.org/thread/AOZ7RFQTQLCZCTVNKESZI67PB3PSS72X/#AOZ7RFQTQLCZCTVNKESZI67PB3PSS72X)
.. [6] [Python-Dev] "str.lstrip bug?"
(https://mail.python.org/archives/list/python-dev@python.org/thread/OJDKRIESKGTQFNLX6KZSGKU57UXNZYAN/#CYZUFFJ2Q5ZZKMJIQBZVZR4NSLK5ZPIH)
.. [7] [Python-Dev] "strip behavior provides inconsistent results with certain strings"
(https://mail.python.org/archives/list/python-dev@python.org/thread/ZWRGCGANHGVDPP44VQKRIYOYX7LNVDVG/#ZWRGCGANHGVDPP44VQKRIYOYX7LNVDVG)
.. [#confusion] Comment listing Bug Tracker and StackOverflow issues .. [#confusion] Comment listing Bug Tracker and StackOverflow issues
(https://mail.python.org/archives/list/python-ideas@python.org/message/GRGAFIII3AX22K3N3KT7RB4DPBY3LPVG/) (https://mail.python.org/archives/list/python-ideas@python.org/message/GRGAFIII3AX22K3N3KT7RB4DPBY3LPVG/)