> > Though it is tempting to head down the language development path, > adding little (or big) features that make it more powerful than > Python itself, I think doing so will actually be counterproductive to > the goals stated above. Perhaps there could be a Cython++ that is a > I'm for the moment considering that using Martin's code here, and extending the approach to have support for "member macros" (that can also be used for operator overloading), numpy.ndarray.__getitem__ could perhaps be implemented quicker if Martin's work is included. Which might "up" the priority. (Not saying that approach is taken, but it is a thought).
As for Cython as a language, one has to consider that also templates, function overloading, and other stuff that it is "natural" to add because we now have a _typed_ (templates overloading) _compiled_ (macros) language. Though perhaps not macros as powerful as these... (shrug) Priorities are a different matter though, and probably most of what I've proposed (as features in themselves, rather than NunPy requirements) might have less priority than getting Python code to run (which is why I should get more down-to-earth with my thoughts about Cython real soon. Which I will.). -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
