[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