PEP 467: incorporate SC feedback

- fromsize: make second parameter `fill=` keyword
- fromord -> fromint

pep-0467.txt

@@ -7,7 +7,7 @@ Status: Draft
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 30-Mar-2014
-Python-Version: 3.10
+Python-Version: 3.11
 Post-History: 2014-03-30 2014-08-15 2014-08-16 2016-06-07 2016-09-01 2021-04-13
 
 
@@ -25,7 +25,7 @@ This PEP proposes five small adjustments to the APIs of the ``bytes`` and
 
 * Discourage passing single integer values to ``bytes`` and ``bytearray``
 * Add ``bytes.fromsize`` and ``bytearray.fromsize`` alternative constructors
-* Add ``bytes.fromord`` and ``bytearray.fromord`` alternative constructors
+* Add ``bytes.fromint`` and ``bytearray.fromint`` alternative constructors
 * Add ``bytes.getbyte`` and ``bytearray.getbyte`` byte retrieval methods
 * Add ``bytes.iterbytes`` and ``bytearray.iterbytes`` alternative iterators
 
@@ -37,7 +37,7 @@ And one built-in::
 Proposals
 =========
 
-Discourage use of current "zero-initialised sequence" behaviour
+Discourage use of current "zero-initialised sequence" behavior
 ---------------------------------------------------------------
 
 Currently, the ``bytes`` and ``bytearray`` constructors accept an integer
@@ -50,7 +50,7 @@ of the given size::
     bytearray(b'\x00\x00\x00')
 
 This PEP proposes to update the documentation to discourage making use of that
-input type dependent behaviour in Python 3.10, suggesting to use a new, more
+input type dependent behavior in Python 3.11, suggesting to use a new, more
 explicit, ``bytes.fromsize(n)`` or ``bytearray.fromsize(n)`` spelling instead
 (see next section).
 
@@ -63,7 +63,7 @@ No other changes are proposed to the existing constructors.
 Addition of explicit "count and byte initialised sequence" constructors
 -----------------------------------------------------------------------
 
-To replace the now discouraged behaviour, this PEP proposes the addition of an
+To replace the now discouraged behavior, this PEP proposes the addition of an
 explicit ``fromsize`` alternative constructor as a class method on both
 ``bytes`` and ``bytearray`` whose first argument is the count, and whose
 second argument is the fill byte to use (defaults to ``\x00``)::
@@ -74,40 +74,37 @@ second argument is the fill byte to use (defaults to ``\x00``)::
     bytearray(b'\x00\x00\x00')
     >>> bytes.fromsize(5, b'\x0a')
     b'\x0a\x0a\x0a\x0a\x0a'
-    >>> bytearray.fromsize(5, b'\x0a')
+    >>> bytearray.fromsize(5, fill=b'\x0a')
     bytearray(b'\x0a\x0a\x0a\x0a\x0a')
 
 ``fromsize`` will behave just as the current constructors behave when passed a
 single integer, while allowing for non-zero fill values when needed.
 
-Similar to ``str.center``, ``str.ljust``, and ``str.rjust``, both parameters
-would be positional-only with no externally visible name.
-
 
 Addition of "bchr" function and explicit "single byte" constructors
 -------------------------------------------------------------------
 
 As binary counterparts to the text ``chr`` function, this PEP proposes
-the addition of a ``bchr`` function and an explicit ``fromord`` alternative
+the addition of a ``bchr`` function and 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.fromord(65)
+    >>> bytes.fromint(65)
     b'A'
-    >>> bytearray.fromord(65)
+    >>> bytearray.fromint(65)
     bytearray(b'A')
 
 These methods will only accept integers in the range 0 to 255 (inclusive)::
 
-    >>> bytes.fromord(512)
+    >>> bytes.fromint(512)
     Traceback (most recent call last):
       File "<stdin>", line 1, in <module>
     ValueError: integer must be in range(0, 256)
 
-    >>> bytes.fromord(1.0)
+    >>> bytes.fromint(1.0)
     Traceback (most recent call last):
       File "<stdin>", line 1, in <module>
     TypeError: 'float' object cannot be interpreted as an integer
@@ -116,15 +113,15 @@ 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.fromord`` case, with
-  ``bytes.fromord`` added for consistency
+* 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.fromord`` and
-``bytearray.fromord`` also exist.
+is the inverse operation for text data, and that ``bytes.fromint`` and
+``bytearray.fromint`` also exist.
 
-Behaviourally, ``bytes.fromord(x)`` will be equivalent to the current
+Behaviorally, ``bytes.fromint(x)`` will be equivalent to the current
 ``bytes([x])`` (and similarly for ``bytearray``). The new spelling is
 expected to be easier to discover and easier to read (especially when used
 in conjunction with indexing operations on binary sequence types).
@@ -185,19 +182,13 @@ type constructor. The immutable ``bytes`` type then inherited that feature
 when it was introduced in PEP 3137.
 
 This PEP isn't revisiting that original design decision, just changing the
-spelling as users sometimes find the current behaviour of the binary sequence
+spelling as users sometimes find the current behavior of the binary sequence
 constructors surprising. In particular, there's a reasonable case to be made
 that ``bytes(x)`` (where ``x`` is an integer) should behave like the
-``bytes.fromord(x)`` proposal in this PEP. Providing both behaviours as separate
+``bytes.fromint(x)`` proposal in this PEP. Providing both behaviors as separate
 class methods avoids that ambiguity.
 
 
-Why use positional-only parameters?
------------------------------------
-
-This is for consistency with the other methods on the affected types, and to
-avoid having to devise sensible names for them.
-
 
 Open Issue: memoryview
 ======================