On Fri, Mar 2, 2012 at 8:29 AM, mark florisson <markflorisson88@gmail.com> wrote:
On 1 March 2012 16:18, Dag Sverre Seljebotn <d.s.seljebotn@astro.uio.no> wrote:
On 03/01/2012 04:03 AM, mark florisson wrote:
On 29 February 2012 17:57, Dag Sverre Seljebotn <d.s.seljebotn@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.
So you are saying we (somehow) stick with supporting "arr.shape[0]" in the future, and perhaps even support "print arr.shape"? (+ arr.dim, arr.strides). Exactly how we could figure out at PyCon.
To remain consistent with previous versions the former should be supported and the latter would be a bonus (and it wouldn't be too hard anyway).
I'm anyway leaning towards deprecating arr.data, as it's too different from what the Python attribute does.
+1 for that, just write &arr[0] as Sturla mentioned. The transition should be trivial.
If there's a confusion due to .data already having a certain meaning with the python attribute, perhaps it would make sense to have an attribute with a different name, eg. .ptr or .voidptr ? IMHO writing &arr[0] looks like a workaround of some kind. Like, when in C you had something like a 2d array and you'd need to interpret it as a 1d array you'd write &arr[0][0], but C array syntax doesn't support attributes which you can add here. Unless of course the idea is to make arrays to behave and look exactly like C counterparts. Dimitri.
Reason I'm asking is that I'm giving a talk on Saturday, and I don't want to teach people bad habits -- so we must figure out what the bad habits are :-) (I think this applies for the PyCon poster as well...)
[1] PyData workshop at Google's offices in Mountain View; the event was open for all but now it is full with a long waiting list, which is why I didn't announce it. http://pydataworkshop.eventbrite.com/
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