> This is what happens with numpy arrays: > > >>> bytes(numpy.array([2], 'i1')) > b'\x00\x00' > > >>> bytes(numpy.array([2, 2], 'i1')) > b'\x02\x02' > > For better or worse, single-element numpy arrays have a working __index__ methods Ouch -- that probably is for the worse.. There are Numpy scalars that should be used for that. > 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. +1 -- though the default should be clear if there isn't one. > 2.1. Accept only objects with a __bytes__ method or a sequence of ints in range(256). If frombuffer() is added, then yes. > 2.2. Expand __bytes__ definition to accept optional encoding and errors parameters. Implement str.__bytes__(self, [encoding[, errors]]). Ouch! I understand the desire to keep a simple API -- but I think encoding clearly belongs with the strong object. What's wrong with: s.encode() ? IIUC, the ONLY object one could possibly encode anyway is a string - 'cause you have to know the internal representation. So bytes() would simply be passing the encoding info off to the string anyway ( or other object with and encode method). > 2.3. Implement new specialized bytes.fromsize and bytes.frombuffer constructors as per PEP 467 and Inada Naoki proposals. Maybe not important -- but nice to have a obvious and perform any way to do it. ( does this proposal allow an initializing value?). For prior art, Numpy has: zeros() ones() empty() And I would like to see an explicit frombuffer() constructor. See others' notes about how using an intermediary memoryview is not obvious and straightforward. -CHB
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