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

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

Ethan Furman writes:

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).

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 one.

Steve

More information about the Python-Dev mailing list