On 02/29/2012 09:42 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 29.02.2012 18:06:
I'm wondering what the best course of action for deprecating the shape
field in numpy.pxd is.
The thing is, currently "shape" really gets in the way. In most situations
it is OK with slow access to shape through the Python layer, and
"arr.shape[0]" is often just fine, but currently one is in a situation
where one must either write "(<object>arr).shape[0])" or
"np.PyArray_DIMS(arr)[0]", or be faced with code that isn't
forward-compatible with NumPy.
Can Cython emulate this at the C layer? And even your work-around for the
Python object access looks more like a Cython bug to me. I wouldn't know
why that can't "just work". It usually works for other undeclared Python
attributes of "anything", so it might just as well be made to work here.
Well, the problem is that shape is currently declared as a C field. It
is also available as a Python attribute. Usually the user doesn't care
which one is used, but the C field is declared for the few cases where
access is speed-critical.
Though even with current NumPy, I find myself doing "print
(<object>arr).shape" in order to get a tuple rather than a Py_ssize_t*...
It would really be good to do the transition as fast as possible, so that
all Cython code eventually becomes ready for upcoming NumPy releases.
But it previously worked, right? It's just no longer supported in newer
NumPy versions IIUC? If that's the case, deleting it would break otherwise
working code. No-one forces you to switch to the latest NumPy version,
after all, and certainly not right now. A warning is much better.
It previously worked, but it turns out that it was always frowned-upon.
I didn't know that when I added the fields, and it was a convenient way
of speeding things up...
Dag
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
