+1 for polishing it and provide option c) as a plugin for now and see how it goes, and discuss inclusion in main Cython after it has proven itself. > I'll have to take a closer look at your proposal and compare it a bit more > to the other approaches we had so far (especially Dag's work), before I > make up my mind about it. Maybe others can already comment a bit deeper on > this. > Since you bring up my name:
a) Clean NumPy integration (that is, with only a pxd file, not a full NumPy plugin) needs some kind of metaprogramming support, but can either work with Martin's explicit approach or my implicit approach, doesn't matter much. (The plan is to not use meta-programming at first, but that will be slow and metaprogramming is key to getting full NumPy speed). b) About my work in relation to this, see the uneval page: http://wiki.cython.org/enhancements/uneval If Martin's work is accepted now, and my own approach for meta-programming is ever done later, then uneval provides a very natural bridge between them. The two seems to be very complementary. Martin's is "explicit" and simple but for advanced users, mine is "easy-to-use" for beginners but more difficult to really understand for advanced users. So doing Martin's first, and then see if my more complicated approach is really needed should be fine as long as uneval provides a natural transition path. uneval() would return the same kind of tree that Martin allows work on, whatever that tree ends up being (as I understand it the exact syntax used is an example, one should add a small API layer on top to isolate it more from Cython core). -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
