On Fri, Mar 2, 2012 at 8:29 AM, mark florisson <markflorisso...@gmail.com> wrote: > On 1 March 2012 16:18, Dag Sverre Seljebotn <d.s.seljeb...@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.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. >> >> >> 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 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
