On 1 March 2012 16:18, Dag Sverre Seljebotn <[email protected]> wrote: > On 03/01/2012 04:03 AM, mark florisson wrote: >> >> On 29 February 2012 17:57, Dag Sverre Seljebotn >> <[email protected]> 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. > 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 > [email protected] > http://mail.python.org/mailman/listinfo/cython-devel _______________________________________________ cython-devel mailing list [email protected] http://mail.python.org/mailman/listinfo/cython-devel
