[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
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=) -> 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