[Python-3000] pre-PEP: Enhancing buffer protocol (tp_as_buffer)
oliphant.travis at ieee.org
Mon Feb 26 19:53:35 CET 2007
>> 2. There is no way for a consumer to tell the protocol-exporting
>>object it is "finished" with its view of the memory and therefore no way
>>for the object to be sure that it can reallocate the pointer to the
>>memory that it owns (the array object reallocating its memory after
>>sharing it with the buffer object led to the infamous buffer-object
> I'm a bit worried about having a get/release kind of thing
> in the protocol, because it risks forcing all objects which
> implement the protocol to provide some kind of refcounting
> and locking mechanism for their data. Some objects may not
> be able to do that easily or efficiently, especially if
> they're wrapping some external library that has no such
If they can't do it easily, then they don't have to define the
release-function and Python will never call it.
>>All that is needed is to create a Python "memory_view" object that can
>>contain all the information needed and be returned when the buffer
>>protocol is called --- when it is garbage-collected, the
>>"bp_release_view" function is called on the exporting object.
> That sounds too heavyweight. Getting a memory view through
> this protocol should be a very lightweight operation -- ideally
> it shouldn't require allocating any memory at all, and it
> certainly shouldn't require creating a Python object.
If you want shape information you are going to have to allocate memory.
If you are going to do that you might as well return a Python object
so you can manage this memory easily.
If you don't want or need shape or detailed type information, I could
also see and have no objection to keeping a lightweight version of the
protocol that only returns simple integers.
I'll put that in the PEP.
More information about the Python-3000