[Python-ideas] Fixing the Python 3 bytes constructor

[Ethan Furman]

On 03/28/2014 07:28 AM, Barry Warsaw wrote:
> Great idea Nick.  If I may dip my brush in some paint buckets.
>
> On Mar 28, 2014, at 08:27 PM, Nick Coghlan wrote:
>
>> However, during a conversation today, a possible solution occurred to
>> me: a "bytes.chr" class method, that served as an alternate
>> constructor. That idea results in the following 3 part proposal:
>>
>> 1. Add "bytes.chr" such that "bytes.chr(x)" is equivalent to the PEP
>> 361 defined "b'%c' % x"
>
> I agree with Steven that bytes.byte() is a better spelling.

+1


>> 2. Add "bytearray.allnull" and "bytes.allnull" such that
>> "bytearray.allnull(x)" is equivalent to the current "bytearray(x)" int
>> handling
>
> I like bytearray.fill() for this.  The first argument would be the fill count,
> but it could take an optional second argument for the byte value to fill it
> with, which would of course default to zero.  E.g.

+1


>> 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)
>
> +1

+1


>> Does the above proposal sound like a reasonable suggestion for improvement in
>> 3.5?

+1

>> Does this hit PEP territory, since it's changing the signature and API
>> of a builtin?
>
> I don't much care either way.  A PEP is not *wrong* (especially if we all
> start painting), but I think a tracker issue would be fine too.

You mean like http://bugs.python.org/issue20895 ?  :)

--
~Ethan~