On 09/01/2016 02:06 PM, Victor Stinner wrote:
2016-09-01 21:36 GMT+02:00 Ethan Furman:
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.
Done.
* 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.
The PEP states that ``bytes(x)`` will not be removed while 2.7 is supported. Once 2.7 is no longer a concern we can visit the question of removing that behavior.
* 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?
- `bchr` to mirror `chr` - `fromord` to replace the mistaken purpose of the default constructor
* Add ``bytes.getbyte`` and ``bytearray.getbyte`` byte retrieval methods * Add ``bytes.iterbytes`` and ``bytearray.iterbytes`` alternative iterators
I like these ones :-)
Cool.
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()?
Oops, fixed. -- ~Ethan