Breaking this into a number of sub-dsicussions, since we seem to be
branching. The original topic was
Re: [Cython] Enhancing "ctyepdef class numpy.ndarray" with getter properties
On 28/09/18 01:20, Robert Bradshaw wrote:
Hmm...so in this case it upgrading Cython would cause an unconditional
switch from direct access to a function call without any code change
(or choice) for users of numpy.pxd. I am curious what kind of a
slowdown this would represent (though would assume this kind of
analysis was done by the NumPy folks when choosing macro vs. function
for the public API).
As I point out in the "experiment" comment referenced above,
pandas has
code that needs lvalue access to ndarray data, so they would be stuck
with the old API which is deprecated but still works for now.
Scipy has
no such code and oculd move forward to the newer API.
But if we upgraded Cython, how would they access the old API? I
suppose they could create a setter macro of their own to use in the
(presumably few) cases where they needed an lvalue.
- Robert
NumPy changed its recommended API to an opaque one via inline getter
functions in 2011, in this PR https://github.com/numpy/numpy/pull/116. I
could not find a discussion on performance impact, perhaps since the
functions are in the header files and marked inline. Hopefully the
compilers will properly deal with making them fast. However, it is true
that when people update to a new version of a library things change. In
this case, there are backward-compatibility macros that revert the
post-1.7 functions into pre-1.7 macros with the same name.
Thus for the experiment I used a new numpy.pxd, defined the pre-1.7 api
in the pandas build (experimental changeset
https://github.com/mattip/pandas/commit/9113bf7e55e1eddece3544c1ad3ef2a761b5210a),
and was still able to access ndarray.data as a lvalue.
Matti
_______________________________________________
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
