> > Here's the latest use case that I wanted: > http://hg.sagemath.org/sage-main/file/ff0875e07b4e/sage/ext/fast_eval.pyx > (starting at line 294--ignore that last case, this is because the > function gets called tens of thousands of times in a row, and I didn't > want an uncommon case to make everything slower). An if-elif > translation would work great here. Interesting. That's in a tight situation and a switch is right, sure. If I understand it correctly (it's an interpreter for a custom stack-based language?) then seeing it kind of makes me want to write a compiler compiling that stack language to native machine code instead, and then one could still use dictionaries as part of the compile phase and get rid of the switch :-)
I'm sure there are better ways to spend our time though. (But it does make me think about perhaps have a real brainstorming some time about possible macro approaches for Cython, and then using macros could actually be a run-time feature of Cython on systems having a C compiler (and one could compile that operation stack using such run-time macros...after getting a ready parse-tree, just call "func = cython.compile(mytree)" and func would point into compiled code). One would not need to compile a new module per macro, a ctypes-approach would be fine for getting the code loaded after compilation.) This is a feature one would think seriously about in 2010 though, not now. What one can start to think about is making some slight changes in the coupling between Main.py and CmdLine.py (in effect reverse the control, have CmdLine.py drive Main.py and not the other way) so that it is possible to use Cython as a library rather than only a program. API and everything would be very unstable for now but just inverting that control flow could be an important mentality change. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
