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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
