Gary Furnish wrote: > I agree. This is very well designed and should hopefully be the > framework for building many of the numpy things without having to > alter the core of cython. Why did you end up using > for relation2 in > your example though? > Apparently you read my example more carefully than I did :-) It should be < of course. (I didn't actually run any code generated with it so I missed it).
Regarding NumPy: - I think type parameters should also be introduced in addition to Cython core. It's an easy job, one avoids a lot of hacks, and they have many potential uses (like C++ templates). - Then, this framework can be used to implement NumPy support. And I think it should be, because it is necasarry to gain experience in this before doing step d), - However, this has a drawback: One still has to know a lot of Cython internals, and when Cython internals change then the transforms will sometimes have to change as well, since the Cython parse tree is exported in "raw" form. - Ideally, one would therefore have yet another layer (built, of course, using this transform layer) that's more geared to specifically doing the transforms necesarry for special support for types. My (now a bit outdated) thoughts on that are on: http://wiki.cython.org/CodeGeneratorPluginArchitecture. But as I said I don't think NumPy support should wait for this layer, rather building NumPy support will show us how such a layer should look like. - Finally, having such a "type specific behaviour" layer will allow NumPy code to be seperated out of Cython development and allow it to live in the NumPy codebase instead (if they want to). Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
