[Python-3000] Single buffer implied in new buffer protocol?

[Travis Oliphant]

Stefan Behnel wrote:
> Hi,
> 
> while implementing Py_buffer support in Cython, I noticed (the hard way,
> throught a segfault), that the buffer pointer passed into getbuffer() can be
> NULL, e.g. when calling memoryview.tobytes(). According to PEP 3118 (first
> paragraph below the getbuffer() signature), this implies setting a lock on the
> memory. Funny enough, the LOCK flag wasn't even set in my case, I just get
> NULL as buffer and 285 as flags...

The memoryview implementation is not yet done.  I'm not sure if that is 
the only issue here.

> 
> Anyway, my point is that this part of the protocol actually implies setting a
> lock on the buffer *provider* rather than the buffer itself, as the buffer
> provider cannot distinguish between different buffers based on a NULL pointer

Yes, the language in the PEP could be more clear.   Obviously, if you 
haven't provided a Py_buffer structure to fill in, then you are only 
asking to lock the object's buffer from other access.

Naturally, the exporter should handle the case when no lock is actually 
requested.

> 
> I know, the protocol is overly complex already and hard to implement from a
> provider perspective, and I understand that that was preferred over putting
> the complexity into the consumer. But wouldn't it make more sense to *always*
> pass the buffer pointer, to let the provider decide what it makes of the
> flags?


Perhaps we are not understanding each other.  The Py_buffer structure 
and the buffer pointer are 2 separate things.  It is the Py_buffer 
structure than can be NULL when getbuffer is called (the buf member of 
the structure is the actual buffer pointer and it is un-defined when 
getbuffer is called and it contains the buffer pointer on successful 
return).

Thanks for your probing.

-Travis