On 29 February 2012 17:57, Dag Sverre Seljebotn <d.s.seljeb...@astro.uio.no> wrote: > 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...
I would personally prefer either cdef nogil extension class properties (needs compiler support) or just special-casing in the compiler, which shouldn't be too hard I think. Warnings would be a first step, but the linkage of ndarray attributes to C attributes is really an implementation detail, so it's better to keep supporting the attributes correctly. > Dag > > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
