[Python-ideas] Fixing the Python 3 bytes constructor
Stephen J. Turnbull
stephen at xemacs.org
Fri Mar 28 12:23:06 CET 2014
Nick Coghlan writes:
> One of the current annoyances with the bytes type in Python 3 is the
> way the constructor handles integers:
>
> >>> bytes(3)
> b'\x00\x00\x00'
>
> It would be far more consistent with the behaviour of other bytes
> interfaces if the result of that call was instead b'\x03'.
+1
~ 13:49$ python3.3
Python 3.3.5 (default, Mar 9 2014, 08:10:50)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> str(3)
'3'
>>> list(3)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
>>> tuple(3)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
The behavior of str(3) is not exactly an argument *for* your claim,
but it's not an argument against since there's no reason to expect a
byte to have an ASCII interpretation in general.
> 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)
bytes.chr(accidental_large_integer) presumably raises. I don't really
see a bigger problem with the current behavior than that (in the
accidentally large case). Both are likely to distress users.
> Anyway, what do people think? Does anyone actually *like* the way the
> bytes constructor in Python 3 currently handles integers and want to
> keep it forever?
No. bytearray I'd have to think about.
> Does the above proposal sound like a reasonable suggestion for
> improvement in 3.5?
Yes.
> Does this hit PEP territory, since it's changing the signature and
> API of a builtin?
No opinion.
Steve
More information about the Python-ideas
mailing list