On Sat, Mar 29, 2014 at 9:49 AM, Ethan Furman <ethan@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