[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Native object exposing buffer protocol

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 

>> 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.