[Python-Dev] Understanding the buffer API

[Stefan Krah]

Nick Coghlan <ncoghlan at gmail.com> wrote:
> Think about trying to specify the buffer protocol using only C++
> references rather than pointers. In Java, it's a lot easier to say
> "this value must be a reference to 'B'" than it is to say "this value
> must be NULL". (My Java is a little rusty, but I'm still pretty sure
> you can only get NullPointerException by messing about with the JNI).
> 
> I think it's worth defining an "OR" clause for each of the current "X
> must be NULL" cases, where it is legal for the provider to emit an
> appropriate non-NULL value that would be consistent with the consumer
> assuming that the returned value is consistent with what they
> requested.

I think any implementation that doesn't use the Py_buffer struct directly
in a C-API should just always return a full buffer if a specific request
can be met according to the rules.


For the C-API, I would be cautious:

   - The number of case splits in testing getbuffer flags is already
     staggering. Defining an "OR" clause would introduce new cases.

   - Consumers may simply rely on the status-quo.


As I said in my earlier mail, for Python 4.0, I'd rather see that buffers
have mandatory full information. Querying individual Py_buffer fields for
NULL should be replaced by a set of flags that would determine contiguity,
buffer "history" (has the buffer been cast to unsigned bytes?) etc.

It would also be possible to add new flags for things like byte order.


The main reason is that it turns out that in any general C function that
takes a Py_buffer argument one has to reconstruct full information anyway,
otherwise obscure cases *will* be overlooked (in the absence of a formal
proof that takes care of all case splits).



Stefan Krah