[Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
ncoghlan at gmail.com
Fri Jun 10 13:40:53 EDT 2016
On 9 June 2016 at 19:21, Barry Warsaw <barry at python.org> wrote:
> On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote:
>>Deprecation of current "zero-initialised sequence" behaviour
>>Currently, the ``bytes`` and ``bytearray`` constructors accept an integer
>>argument and interpret it as meaning to create a zero-initialised sequence of
>>the given size::
>> >>> bytes(3)
>> >>> bytearray(3)
>>This PEP proposes to deprecate that behaviour in Python 3.6, and remove it
>>entirely in Python 3.7.
>>No other changes are proposed to the existing constructors.
> Does it need to be *actually* removed? That does break existing code for not
> a lot of benefit. Yes, the default constructor is a little wonky, but with
> the addition of the new constructors, and the fact that you're not proposing
> to eventually change the default constructor, removal seems unnecessary.
> Besides, once it's removed, what would `bytes(3)` actually do? The PEP
> doesn't say.
Raise TypeError, presumably. However, I agree this isn't worth the
hassle of breaking working code, especially since truly ludicrous
values will fail promptly with MemoryError - it's only a particular
range of values that fit within the limits of the machine, but also
push it into heavy swapping that are a potential problem.
> Also, since you're proposing to add `bytes.byte(3)` have you considered also
> adding an optional count argument? E.g. `bytes.byte(3, count=7)` would yield
> b'\x03\x03\x03\x03\x03\x03\x03'. That seems like it could be useful.
The purpose of bytes.byte() in the PEP is to provide a way to
roundtrip ord() calls with binary inputs, since the current spelling
is pretty unintuitive:
That said, perhaps it would make more sense for the corresponding
round-trip to be:
With the "b" prefix on "chr" reflecting the "b" prefix on the output.
This also inverts the chr/unichr pairing that existed in Python 2
(replacing it with bchr/chr), and is hence very friendly to
compatibility modules like six and future (future.builtins already
provides a chr that behaves like the Python 3 one, and bchr would be
much easier to add to that than a new bytes object method).
In terms of an efficient memory-preallocation interface, the
equivalent NumPy operation to request a pre-filled array is
(there's also an inplace mutation operation, "fill")
For bytes and bytearray though, that has an unfortunate name collision
with "zfill", which refers to zero-padding numeric values for fixed
If the PEP just added bchr() to complement chr(), and [bytes,
bytearray].zeros() as a more discoverable alternative to passing
integers to the default constructor, I think that would be a decent
step forward, and the question of pre-initialising with arbitrary
values can be deferred for now (and perhaps left to NumPy
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev