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
_______________________________________________
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
