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