[Python-ideas] Fixing the Python 3 bytes constructor

[Stephen J. Turnbull]

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