Native object exposing buffer protocol
Rob Gaddi
rgaddi at highlandtechnology.invalid
Mon Jan 8 19:59:32 EST 2018
On 01/05/2018 04:27 PM, Ben Finney wrote:
> Rob Gaddi <rgaddi at highlandtechnology.invalid> writes:
>
>> I'd like to create a native Python object that exposes the buffer
>> protocol. Basically, something with a ._data member which is a
>> bytearray that I can still readinto, make directly into a numpy array,
>> etc.
>
> The “etc.” seems pretty important, there. You want the behaviour of
> ‘bytearray’ without actually inheriting that behaviour from the
> ‘bytearray’ type. >
Well, one specific behavior. Ideally, what I want is, when calls like
RawIOBase.readinto and ndarray.frombuffer ask my class "Hey, do you have
any raw bytes that I can read and potentially write?" it can answer "Why
certainly, here they are." Something like a:
class Thingy:
def __memoryview__(self):
return memoryview(self._data)
But it doesn't look as if there's a dunder for that. There's __bytes__,
but that specifically requires you give back a bytes() object; even
returning a bytearray causes an error.
> So, it seems your options are:
>
> * Enumerate all the things, specifically, that you do want your new type
> to do. Don't hide anything in “etc.”, so that you know exactly what
> behaviours need to be implemented. Implement all those behaviours,
> without benefit of inheriting from ‘bytearray’.
>
> * Inherit from ‘bytearray’, but ameliorate the problems you want to
> avoid. This will require enumerating all those problems, so that you
> can know whether you have avoided them. Don't hide any of them in an
> “etc.”.
That's ultimately the way I'm going about it, but since this is only
going to get used in-house, I'm approaching it the Pythonic way. The
problem is "Most methods of bytearray make no sense on a data structure
representing a fixed length waveform." The solution is "Well, don't use
them."
>
>> Not the end of the world (the file's less than 2KB), but it seems like
>> something that should be doable easily without having to throw around
>> a lot of extraneous copies.
>
> I look forward to your report from having tried it :-)
>
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
More information about the Python-list
mailing list