[Numpy-discussion] np 1.7b2 PyArray_BYTES(obj)=ptr fail

Charles R Harris charlesr.harris at gmail.com
Tue Oct 2 18:18:58 EDT 2012

On Tue, Oct 2, 2012 at 1:44 PM, Frédéric Bastien <nouiz at nouiz.org> wrote:

> With numpy 1.6.2, it is working. So this is an interface change. Are
> you sure you want this? This break existing code.
> I do not understand what you mean by slot?

Pythonese for structure member ;)

> I'm not sure is the PyArray_SWAP is a good long term idea. I would not
> make it if it is only for temporarily.

The C++ stdlib provides something similar for std::vector. One common use
case would be to pass in a vector by reference that gets swapped with one
on the stack. When the function exits the one on the stack is cleaned up
and the vector that was passed in has the new data, but it has to be the
same type.

For PyArray_SWAP I was thinking of swapping everything: type, dims,
strides, data, etc. That is what f2py does.

> To set the base ptr, there is PyArray_SetBaseObject() fct that is new
> in 1.7. Is a similar fct useful in the long term for numpy? In the
> case where we implement differently the ndarray object, I think it
> won't be useful. We will also need to know how the memory is laid out
> by numpy for performance critical code. We we will need an attribute
> that tell the intern structure used.
> So do you want to force this interface change in numpy 1.7 so that I
> need to write codes now or can I wait to do it when you force the new
> interface?
Well, no we don't want to force you to use the new interface. If you don't
define NPY_NO_DEPRECATED_API things should still work. Although if it is
defined the function returns an rvalue, so some other method needs to be
provided for what you are doing.

> Currently the used code for PyArray_BYTES is:
> #define PyArray_BYTES(obj) ((char *)(((PyArrayObject_fields
> *)(obj))->data))
> if I change it to
> #define PyArray_BYTES(obj) ((((PyArrayObject_fields *)(obj))->data))
> it work! I don't understand why removing the case make it work. the
> data field is already an (char*), so this should not make a difference
> to my underderstanding. But I'm missing something here, do someone
> know?

What I find strange is that it is the same macro in 1.7 and 1.6, only the
name of the structure was changed. Hmm... This looks almost like some
compiler subtlety, I wonder if the compiler version/optimization flags have
changed? In any case, I think the second form would be more correct for the
lvalue since the structure member is, as you say, already a char*.

We want things to work for you as they should, so we need to understand
this and fix it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20121002/a2538831/attachment.html>

More information about the NumPy-Discussion mailing list