[Python-3000] pre-PEP: Enhancing buffer protocol (tp_as_buffer)

[Travis Oliphant]

> 
>>   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 
>>problem).
> 
>
> 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
> notion.

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.

-Travis