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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4