On May 10, 2008, at 3:14 AM, Dag Sverre Seljebotn wrote: > 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. > >>> On the other hand, one has to remember to do "print y.shape" for >>> tuple-access but "y.dimensions[i]" for speedy, non-Python access. >>> (And this difference in behaviour comes entirely from strides >>> having a name- clash while shape/dimensions do not). >> This is a numpy api issue, nothing to do with Cython. > 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.
Yes, this I was talking about the NumPy C API being different from the NumPy Py 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. I think both goals are important, and can coincide. Our target audience is SciPy developers as well as SciPy users. > 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). Incidentally, some of the classes may be implemented in Cython (there is a relevant GSoC for the SciPy folks on this), but that is completely besides the point. Looking at my example, I had a.pxd and b.pyx that used a.A. If A was implemented in Cython or pure C it made no difference. > 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. Yes, any actual code in a pxd file is an "overlay" as you call it. But semantically it belongs to the class, and should be used whenever that class is used. Code in a .pyx file is compiled to the module. Code in a .pxd file is only used to help compile other modules. > 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. No problem. BTW, did you have any comments about my proposal for how use parameterize types? - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
