To recap the motivation for having it in base Cython: - C++ template metaprogramming shows the value of compile time metaprogramming, i.e. writing programs that run at compile time and that produce programs as their output.
- However, C++ templates are essentially a separate, purely functional programming language embedded in C++, with different syntax and semantics than C+. Of course, they were never really intended or designed for metaprogramming. But now that they're being used that way, it's clear that the substitution model of templates is awkward and unnatural. If we're going to write little functions to run at compile time, it makes sense to use the syntax and semantics of the base language. Compile time metaprogramming doesn't exist in Python, so adding it to Cython means extending Cython beyond what Python has. There are a couple options: 1. Add a way to generate C++ templates, and use that for metaprogramming. It keeps Cython as "writing both Python and C++ with an extended Python syntax." 2. Don't add metaprogramming, even C++ templates. Keeps Cython close to Python and C and C++, including all the good & bad parts. 3. Add a way to specify Python code for the transformation. This recognizes that metaprogramming is a valuable activity that Cython developers will want to do; that the existing way to do it in C++ is more-or-less not up to the task; and that it's better to provide a new, cleaner mechanism using what we've learned in hindsight. Of course, metaprogramming in an imperative, stateful language, opens a can of worms, e.g. it will be valuable to modify Python data at compile time, and have that serialized once all transforming is done, then loaded at the start of runtime. I don't think any of these problems are particularly difficult though. So, what do people this is the best way forward for Cython? Best, Martin _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
