On 01/05/2018 04:27 PM, Ben Finney wrote:
Rob Gaddi <rgaddi@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.
--
https://mail.python.org/mailman/listinfo/python-list
