[Python-checkins] peps: PEP 467: Additional tweaks after re-reading

nick.coghlan python-checkins at python.org
Sun Mar 30 03:55:05 CEST 2014


http://hg.python.org/peps/rev/7d095b0d3109
changeset:   5448:7d095b0d3109
user:        Nick Coghlan <ncoghlan at gmail.com>
date:        Sun Mar 30 11:54:55 2014 +1000
summary:
  PEP 467: Additional tweaks after re-reading

files:
  pep-0467.txt |  40 +++++++++++++++++++++++++++++-----------
  1 files changed, 29 insertions(+), 11 deletions(-)


diff --git a/pep-0467.txt b/pep-0467.txt
--- a/pep-0467.txt
+++ b/pep-0467.txt
@@ -138,6 +138,7 @@
 explicit that it is an alternate constructor rather than an in-place
 mutation, as well as how it differs from the standard constructor.
 
+
 Open questions
 ^^^^^^^^^^^^^^
 
@@ -145,12 +146,13 @@
   ``bytearray(bytes.byte(x))`` sufficient for that case?
 * Should ``bytes.from_len()`` also be added? Or is sequence repetition
   sufficient for that case?
-* Should ``bytearry.from_len()`` use a different name?
+* Should ``bytearray.from_len()`` use a different name?
 * Should ``bytes.byte()`` raise ``TypeError`` or ``ValueError`` for binary
   sequences with more than one element? The ``TypeError`` currently proposed
-  is copied from the behaviour of ``ord()`` with strings containing more
-  than one code point, while ``ValueError`` would be more consistent with
-  the existing handling of out-of-range integer values.
+  is copied (with slightly improved wording) from the behaviour of ``ord()``
+  with sequences containing more than one code point, while ``ValueError``
+  would be more consistent with the existing handling of out-of-range
+  integer values.
 * ``bytes.byte()`` is defined above as accepting length 1 binary sequences
   as individual bytes, but this is currently inconsistent with the main
   ``bytes`` constructor::
@@ -164,6 +166,7 @@
   bytes objects in addition to iterables of integers? If so, should it
   allow a mixture of the two in a single iterable?
 
+
 Iteration
 ---------
 
@@ -180,8 +183,8 @@
         # 0 to 255 inclusive
 
 
-Consistently accepting integer inputs to methods
-------------------------------------------------
+Consistent support for different input types
+--------------------------------------------
 
 In Python 3.3, the binary search operations (``in``, ``count()``,
 ``find()``, ``index()``, ``rfind()`` and ``rindex()``) were updated to
@@ -191,7 +194,9 @@
 This PEP proposes extending that behaviour of accepting integers as being
 equivalent to the corresponding length 1 binary sequence to several other
 ``bytes`` and ``bytearray`` methods that currently expect a ``bytes``
-object for certain parameters.
+object for certain parameters. In essence, if a value is an acceptable
+input to the new ``bytes.byte`` constructor defined above, then it would
+be acceptable in the roles defined here:
 
 * ``startswith()`` prefix(es)
 * ``endswith()`` suffix(es)
@@ -200,9 +205,9 @@
 * ``ljust()`` fill character
 * ``rjust()`` fill character
 
-* ``strip()`` characters to strip
-* ``lstrip()`` characters to strip
-* ``rstrip()`` characters to strip
+* ``strip()`` character to strip
+* ``lstrip()`` character to strip
+* ``rstrip()`` character to strip
 
 * ``partition()`` separator argument
 * ``rpartition()`` separator argument
@@ -216,13 +221,22 @@
 to work with the indexing behaviour , as the result of an indexing operation
 can more easily be fed back in to other methods.
 
+For ``bytearray``, some additional changes are proposed to the current
+integer based operations to ensure they remain consistent with the proposed
+constructor changes::
+
+* ``append()``: updated to be consistent with ``bytes.byte()``
+* ``remove()``: updated to be consistent with ``bytes.byte()``
+* ``+=``: updated to be consistent with ``bytes()`` changes (if any)
+* ``extend()``: updated to be consistent with ``bytes()`` changes (if any)
+
 
 Acknowledgement of surprising behaviour of some ``bytearray`` methods
 ---------------------------------------------------------------------
 
 Several of the ``bytes`` and ``bytearray`` methods have their origins in the
 Python 2 ``str`` API. As ``str`` is an immutable type, all of these
-operations are defined as returning a *new* instances, rather than operating
+operations are defined as returning a *new* instance, rather than operating
 in place. This contrasts with methods on other mutable types like ``list``,
 where ``list.sort()`` and ``list.reverse()`` operate in-place and return
 ``None``, rather than creating a new object.
@@ -253,10 +267,14 @@
 they're part of the mutable sequence API in ``bytearray``, rather than being
 inspired by the immutable Python 2 ``str`` API:
 
+* ``+=``
+* ``append()``
+* ``extend()``
 * ``reverse()``
 * ``remove()``
 * ``pop()``
 
+
 References
 ==========
 

-- 
Repository URL: http://hg.python.org/peps


More information about the Python-checkins mailing list