PEP 467: Drop the bchr builtin proposal

pep-0467.txt

@@ -29,10 +29,6 @@ This PEP proposes five small adjustments to the APIs of the ``bytes`` and
 * Add ``bytes.getbyte`` and ``bytearray.getbyte`` byte retrieval methods
 * Add ``bytes.iterbytes`` and ``bytearray.iterbytes`` alternative iterators
 
-And one built-in::
-
-* ``bchr``
-
 
 Proposals
 =========
@@ -81,17 +77,13 @@ second argument is the fill byte to use (defaults to ``\x00``)::
 single integer, while allowing for non-zero fill values when needed.
 
 
-Addition of "bchr" function and explicit "single byte" constructors
--------------------------------------------------------------------
+Addition of explicit "single byte" constructors
+-----------------------------------------------
 
 As binary counterparts to the text ``chr`` function, this PEP proposes
-the addition of a ``bchr`` function and an explicit ``fromint`` alternative
-constructor as a class method on both ``bytes`` and ``bytearray``::
+the addition of an explicit ``fromint`` alternative constructor as a class
+method on both ``bytes`` and ``bytearray``::
 
-    >>> bchr(ord("A"))
-    b'A'
-    >>> bchr(ord(b"A"))
-    b'A'
     >>> bytes.fromint(65)
     b'A'
     >>> bytearray.fromint(65)
@@ -109,17 +101,10 @@ These methods will only accept integers in the range 0 to 255 (inclusive)::
       File "<stdin>", line 1, in <module>
     TypeError: 'float' object cannot be interpreted as an integer
 
-While this does create some duplication, there are valid reasons for it:
-
-* the ``bchr`` builtin is to recreate the ``ord``/``chr``/``unichr`` trio from
-  Python 2 under a different naming scheme
-* the class method is mainly for the ``bytearray.fromint`` case, with
-  ``bytes.fromint`` added for consistency
-
 The documentation of the ``ord`` builtin will be updated to explicitly note
-that ``bchr`` is the primary inverse operation for binary data, while ``chr``
-is the inverse operation for text data, and that ``bytes.fromint`` and
-``bytearray.fromint`` also exist.
+that ``bytes.fromint`` is the primary inverse operation for binary data, while
+``chr`` is the inverse operation for text data, and that ``bytearray.fromint``
+also exists.
 
 Behaviorally, ``bytes.fromint(x)`` will be equivalent to the current
 ``bytes([x])`` (and similarly for ``bytearray``). The new spelling is
@@ -129,6 +114,14 @@ in conjunction with indexing operations on binary sequence types).
 As a separate method, the new spelling will also work better with higher
 order functions like ``map``.
 
+These new methods intentionally do NOT offer the same level of general integer
+support as the existing ``int.to_bytes`` conversion method, which allows
+arbitrarily large integers to be converted to arbitarily long bytes objects. The
+restriction to only accept positive integers that fit in a single byte means
+that no byte order information is needed, and there is no need to handle
+negative numbers. The documentation of the new methods will refer readers to
+``int.to_bytes`` for use cases where handling of arbitrary integers is needed.
+
 
 Addition of "getbyte" method to retrieve a single byte
 ------------------------------------------------------
@@ -189,11 +182,28 @@ that ``bytes(x)`` (where ``x`` is an integer) should behave like the
 class methods avoids that ambiguity.
 
 
+Omitting the originally proposed builtin function
+-------------------------------------------------
+
+When submitted to the Steering Council, this PEP proposed the introduction of
+a ``bchr`` builtin (with the same behaviour as ``bytes.fromint``), recreating
+the ``ord``/``chr``/``unichr`` trio from Python 2 under a different naming
+scheme (``ord``/``bchr``/``chr``).
+
+The SC indicated they didn't think this functionality was needed often enough
+to justify offering two ways of doing the same thing, especially when one of
+those ways was a new builtin function. That part of the proposal was therefore
+dropped as being redundant with the ``bytes.fromint`` alternate constructor.
+
+Developers that use this method frequently will instead have the option to
+define their own ``bchr = bytes.fromint`` aliases.
+
 
-Open Issue: memoryview
-======================
+Scope limitation: memoryview
+----------------------------
 
-Updating ``memoryview`` with these new methods is outside the scope of this PEP.
+Updating ``memoryview`` with the new item retrieval methods is outside the scope
+of this PEP.
 
 
 References