[Python-Dev] PEP 3118: Extended buffer protocol (new version)

[Travis Oliphant]

Carl Banks wrote:
>
>
> Travis Oliphant wrote:
> > Py_BUF_READONLY
> >    The returned buffer must be readonly and the underlying object 
> should make
> >    its memory readonly if that is possible.
>
> I don't like the "if possible" thing.  If it makes no guarantees, it 
> pretty much useless over Py_BUF_SIMPLE.
O.K.  Let's make it raise an error if it can't set it read-only.

>> Py_BUF_FORMAT
>>    The consumer will be using the format string information so make 
>> sure that    member is filled correctly. 
>
> Is the idea to throw an exception if there's some other data format 
> besides "b", and this flag isn't set?  It seems superfluous otherwise.

The idea is that a consumer may not care about the format and the 
exporter may want to know that to simplify the interface.    In other 
words the flag is a way for the consumer to communicate that it wants 
format information (or not). 

If the exporter wants to raise an exception if the format is not 
requested is up to the exporter.

>> Py_BUF_SHAPE
>>    The consumer can (and might) make use of using the ndims and shape 
>> members of the structure
>>    so make sure they are filled in correctly.    Py_BUF_STRIDES 
>> (implies SHAPE)
>>    The consumer can (and might) make use of the strides member of the 
>> structure (as well
>>    as ndims and shape)
>
> Is there any reasonable benefit for allowing Py_BUF_SHAPE without 
> Py_BUF_STRIDES?  Would the array be C- or Fortran-like?

Yes,  I could see a consumer not being able to handle simple striding 
but could handle shape information.  Many users of NumPy arrays like to 
think of the array as an N-d array but want to ignore striding.

I've made the changes in numpy's SVN.   Hopefully they will get mirrored 
over to the python PEP directory eventually.

-Travis