[Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

Stephen J. Turnbull stephen at xemacs.org
Wed Jun 8 02:48:58 EDT 2016

Ethan Furman writes:

 > * Deprecate passing single integer values to ``bytes`` and
 >   ``bytearray``

Why?  This is a slightly awkward idiom compared to .zeros (EITBI etc),
but your 32-bit clock will roll over before we can actually remove it.
There are a lot of languages that do this kind of initialization of
arrays based on ``count``.  If you want to do something useful here,
add an optional argument (here in ridiculous :-) generality:

    bytes(count, tile=[0]) -> bytes(tile * count)

where ``tile`` is a Sequence of a type that is acceptable to bytes
anyway, or Sequence[int], which is treated as

    b"".join([bytes(chr(i)) for i in tile] * count])

Interpretation of ``count`` of course  i bikesheddable, with at least
one alternative interpretation (length of result bytes, with last tile
truncated if necessary).

 > * Add ``bytes.zeros`` and ``bytearray.zeros`` alternative constructors

this is an API break if you take the deprecation as a mandate (which
eventual removal does indicate).  And backward compatibility for
clients of the bytes API means that we violate TOOWTDI indefinitely,
on a constructor of quite specialized utility.  Yuck.

-1 on both.

Barry Warsaw writes later in thread:

 > We can't change bytes.__getitem__ but we can add another method
 > that returns single byte objects?  I think it's still a bit of a
 > pain to extract single bytes even with .iterbytes().

+1  ISTM that more than the other changes, this is the most important


More information about the Python-Dev mailing list