2016-09-01 21:36 GMT+02:00 Ethan Furman <ethan@stoneleaf.us>:
Abstract ========
This PEP proposes five small adjustments to the APIs of the ``bytes`` and ``bytearray`` types to make it easier to operate entirely in the binary domain:
You should add bchr() in the Abstract.
* Deprecate passing single integer values to ``bytes`` and ``bytearray`` * Add ``bytes.fromsize`` and ``bytearray.fromsize`` alternative constructors
I understand that main reason for this change is to catch bugs when bytes(obj) is used and obj is not supposed to be an integer. So I expect that bytes(int) will be quickly deprecated, but the PEP doesn't schedule a removal of the feature. So it looks more than only adding an alias to bytes(int). I would prefer to either schedule a removal of bytes(int), or remove bytes.fromsize() from the PEP.
* Add ``bytes.fromord`` and ``bytearray.fromord`` alternative constructors
Hum, you already propose to add a builtin function. Why would we need two ways to create a single byte? I'm talking about bchr(int)==bytes.fromord(int). I'm not sure that there is an use case for bytearray.fromord(int).
* Add ``bytes.getbyte`` and ``bytearray.getbyte`` byte retrieval methods * Add ``bytes.iterbytes`` and ``bytearray.iterbytes`` alternative iterators
I like these ones :-)
In particular, there's a reasonable case to be made that ``bytes(x)`` (where ``x`` is an integer) should behave like the ``bytes.fromint(x)`` proposal in this PEP.
"fromint"? Is it bytes.fromord()/bchr()?
Open Questions ==============
Do we add ``iterbytes`` to ``memoryview``, or modify ``memoryview.cast()`` to accept ``'s'`` as a single-byte interpretation? Or do we ignore memory for now and add it later?
It's nice to have bytes.iterbytes() to help porting Python 2 code, but I'm not sure that this function would be super popular in new Python 3 code. I don't think that a memoryview.iterbytes() (or cast("s")) would be useful. Victor