Hi,

I made a PR with my fix:

https://github.com/numpy/numpy/pull/2709

Frédéric


On Tue, Oct 2, 2012 at 6:18 PM, Charles R Harris
<charlesr.har...@gmail.com>wrote:

>
>
> On Tue, Oct 2, 2012 at 1:44 PM, Frédéric Bastien <no...@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.
>
> <snip>
>
> Chuck
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to