Thanks for the feedback, I have no problems seeing weaknesses in my
suggestion, but I think there are real issues here that you don't
address either.Sure. Remember however: Which API are we talking about here, when we say "NumPy API"? When using the extension type, that is essentially the C API. Basically, this seem to imply: a) The NumPy community has to provide a stable API for their extension type (i.e. stable API in header files) b) ...that lies close to the Python API What I'd like is to have support for a thin layer in the pxd file so that one is able to emulate/reimplement parts of the _Python_ API. Then, that pxd file can be shipped with NumPy, and if changes are made to the C API/extension type then just change and ship a new pxd as well; client code remains the same. This is so that code written in Python towards the Python NumPy API can simply be typed and compiled. The "NumPy C API" (which is what is really used when one declares extension types etc.) is however really a different API to NumPy, and so one cannot in general assume that one will ever be able to simply "type and compile" Python code towards it. My point is that we would like this to be attractive for current Python users, using the current Python API. The less they have to know about the C API the better, and then relying on "fudging" the C API to "almost look like" the Python API doesn't seem to cut it. Ahhh.... We might have slightly different goals here? That is, can you agree with this statement?: * Your goal is making writing Cython code towards the NumPy "C API" (extension type etc.) a little more convenient * My goal is to start with the Python API and simply speed it up. Then that is perhaps a fundamental question that should be resolved first. And I do not think they can coincide, that is discussable as well. On to your suggestion: In your prototype you use the "cdef class". Sure, for classes implemented in Cython the C API and Python API coincide, but that is not so for other extension types. Do you mean to imply that NumPy ndarrays will have to be reimplemented entirely in Cython in order to generate effective code for then? I don't think that will happen (nor should it be necesarry). If one changes your example slightly and putting the __getitem__ in a cdef struct for an extension type then you end up "putting them in some overlay", since the real implementation is in another module (written in C). I just wanted to make the overlay more explicit, or if it is not explicit in the syntax as such, at least we need to know that that is what we're doing. BTW, as I said, the "different name thing" was something I hoped to get rid of, it was just to make it clear what was happpening. Sorry, that was a bit confusing. -- Dag Sverre |
_______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
