[Python-Dev] Adding bytes.frombuffer() constructor to PEP 467
Chris Barker - NOAA Federal
chris.barker at noaa.gov
Tue Jan 10 12:42:49 EST 2017
> 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
More information about the Python-Dev
mailing list