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