RetroSearch Browse

Tue Apr 10 01:59:41 CEST 2007 · https://mail.python.org/pipermail/python-dev/2007-April/072540.html

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.

> 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.

> 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?

Another little mistake I made: looking at the Python source, it seems 
that most C defines do not use the Py_ prefix, so probably we shouldn't 
here.  Sorry.

Carl

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-April/072540.html below:

Extended buffer protocol (new version)