[Numpy-discussion] Array interface updated to Version 3

[David M. Cooke]

On Tue, 20 Jun 2006 21:05:51 +0200
Thomas Heller <theller at python.net> wrote:

> Travis Oliphant schrieb:
> > I just updated the array interface page to emphasize we now have version 
> > 3.  NumPy still supports  objects that expose (the C-side) of version 2 
> > of the array interface, though. 
> > 
> > The new interface is basically the same except (mostly) for asthetics:  
> > The differences are listed at the bottom of
> > 
> > http://numeric.scipy.org/array_interface.html
> > 
> > There is talk of ctypes supporting the new interface which is a worthy 
> > development.  Please encourage that if you can.
> > 
> > Please voice concerns now if you have any.
> 
>  From http://numeric.scipy.org/array_interface.html:
> """
> New since June 16, 2006:
> For safety-checking the return object from PyCObject_GetDesc(obj) should 
> be a Python Tuple with the first object a Python string containing 
> "PyArrayInterface Version 3" and whose second object is a reference to 
> the object exposing the array interface (i.e. self).
> 
> Older versions of the interface used the "desc" member of the PyCObject 
> itself (do not confuse this with the "descr" member of the 
> PyArrayInterface structure above --- they are two separate things) to 
> hold the pointer to the object exposing the interface, thus you should 
> make sure the object returned is a Tuple before assuming it is in a 
> sanity check.
> 
> In a sanity check it is recommended to only check for "PyArrayInterface 
> Version" and not for the actual version number so that later versions 
> will still be compatible.  The old sanity check for the integer 2 in the 
> first field is no longer necessary (but it is necessary to place the 
> number 2 in that field so that objects reading the old version of the 
> interface will still understand this one).
> """
> 
> I know that you changed that because of my suggestions, but I don't 
> think it should stay like this.
> 
> The idea was to have the "desc" member of the PyCObject a 'magic value'
> which can be used to determine that the PyCObjects "void *cobj" pointer
> really points to a PyArrayInterface structure.  I have seen PyCObject 
> uses before in this way, but I cannot find them any longer.
> 
> If current implementations of the array interface use this pointer for
> other things (like keeping a reference to the array object), that's 
> fine, and I don't think the specification should change.  I think it is
> espscially dangerous to assume that the desc pointer is a PyObject 
> pointer,  Python will segfault if it is not.

> I suggest that you revert this change.

When I initially proposed the C version of the array interface, I suggested
using a magic number, like 0xDECAF (b/c it's lightweight :-) as the first
member of the CObject. Currenty, we use a version number, but I believe that
small integers would be more common in random CObjects than a magic number. We
could do similiar, using 0xDECAF003 for version 3, for instance.

That would keep most of the benefits of an explicit "this is an array
interface" CObject token, but is lighter to check, and doesn't impose any
constraints on implementers for their desc fields.

One of the design goals for the C interface was speed; doing a check that the
first member of a tuple begins with a certain string slows it down.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca