Martin C. Martin wrote: > Compile time metaprogramming doesn't exist in Python, so adding it to > Cython means extending Cython beyond what Python has.
Cython has a couple of additional features that make sense because it is a compiled language. I think what you call "metaprogramming" (and generally most things that allow doing things at compile-time instead of run-time) makes sense for Cython. > 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." But that would be C++ specific and can't work with C. > 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. I would say so. I would currently position it as a) an extension mechanism for Cython itself and b) an advanced feature that most people won't use (in the same way most people don't use metaclasses) - but as usual with OSS, you never know what people will use it for. > 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? 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. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
