On 05.01.17 22:37, Alexander Belopolsky wrote:
I propose the following:
1. For 3.6, restore and document 3.5 behavior. Recommend that 3rd party
types that are both integer-like and buffer-like implement their own
__bytes__ method to resolve the bytes(x) ambiguity.
The __bytes__ method is used only by the bytes constructor, not by the
bytearray constructor.
2. For 3.7, I would like to see a drastically simplified bytes(x):
2.1. Accept only objects with a __bytes__ method or a sequence of ints
in range(256).
2.2. Expand __bytes__ definition to accept optional encoding and errors
parameters. Implement str.__bytes__(self, [encoding[, errors]]).
I think it is better to use the encode() method if you want to encode
from non-strings.
2.3. Implement new specialized bytes.fromsize and bytes.frombuffer
constructors as per PEP 467 and Inada Naoki proposals.
bytes.fromsize(n) is just b'\0'*n. I don't think this method is needed.
bytes.frombuffer(x) is bytes(memoryview(x)) or memoryview(x).tobytes().
2.4. Implement memoryview.__bytes__ method so that bytes(memoryview(x))
works ad before.
2.5. Implement a fast bytearray.__bytes__ method.
This wouldn't help for the bytearray constructor. And wouldn't allow to
avoid double copying in the constructor of bytes subclass.
3. Consider promoting __bytes__ to a tp_bytes type slot.
The buffer protocol is more general than the __bytes__ method. It allows
to avoid redundant memory copying in constructors of many types (bytes,
bytearray, array.array, etc), not just bytes.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
