Home Original page

[Python-Dev] PEP 467: last round (?)

Ethan Furman ethan at stoneleaf.us
Thu Sep 1 18:04:33 EDT 2016 
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
More information about the Python-Dev mailing list