[Python-ideas] Fixing the Python 3 bytes constructor

[Barry Warsaw]

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.

>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.

>>> bytearray.fill(5)
bytearray(b'\x00\x00\x00\x00\x00')
>>> bytearray.fill(5, 97)
bytearray(b'aaaaa')

>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

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

Very much so.

>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.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140328/03763789/attachment.sig>