[Python-ideas] Fixing the Python 3 bytes constructor

[Gregory P. Smith]

On Sat, Mar 29, 2014 at 9:49 AM, Ethan Furman <ethan at stoneleaf.us> wrote:

> On 03/28/2014 03:27 AM, Nick Coghlan wrote:
>
>>
>> 3. Deprecate the current "bytes(x)" and "bytearray(x)" int handling as
>> not only ambiguous, but actually a genuine bug magnet (it's way too
>> easy to accidentally pass a large integer and try to allocate a
>> ridiculously large bytes object)
>>
>
> Why do 'bytes' and 'bytearray' have to have exactly the same API?  Having
> 'bytearray(10)' return a zero filled array is fine, as bytearrays are
> mutable; it just doesn't make sense for 'bytes' which are immutable.
>
>
I agree they didn't need to be. But that's already happened. Consistency
*is* convenient when reading and re-factoring code.

Regardless, the real issue is that it is easy to inadvertently pass an
integer to the bytes() constructor [and thus the bytearray() constructor]
when you really intended to pass a single element sequence.

+1 Deprecating the single integer argument to the constructor in 3.5
(DeprecationWarning) to be considered for removal in 3.6 or 3.7 sounds like
a good idea.

+1 At the same time, adding class methods: bytes*.byte*(97) and bytearray
*.byte*(0x65) sound great. Those are *always explicit* about the
programmer's intent rather than being an overloaded constructor that does
different things based on the type passed in which is more prone to bugs.

+1 that *bytearray*() does need a constructor that pre-allocates a bunch of
empty (zero) space as that is a common need for a mutable type.  That
should be .*zfill*(n) for consistency. Filling with other values is way
less common and doesn't deserve a .fill(n, value) method with potentially
ambiguous parameters (which one is the count and which one is the value
again? that'll be a continual question just as it is for C's memset and
similar functions).

-0 on the idea of a .zeros(n), .zeroes(n), .fill(n, value) or .zfill(n)
class methods for the *bytes*() type. That is fine written as bytes.byte(0)
* n as it is expected to be an uncommon operation.  But if you want to add
it for consistency, fine by me, change the sign of my preference. :)

I don't think this is worthy of a PEP but won't object if you go that route.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140329/3aa42880/attachment.html>