Dag Sverre Seljebotn wrote: > The places where result_code is used during analysis should go anyway;
I agree. It's not trivial in all cases, though. Cython has a couple of optimisations and enhancements that rely on replacing a node by a different one, which may then need a constant value at creation time in some cases. The exception value that is used in CFuncDeclaratorNode to set up the function type is one example that I'm currently trying to work around. Another example is IntNode, which is expected to return a plain constant result all the time, but actually requires the compile time code writer to cache Python integers before it knows its result code. This would be easier to solve if the pipeline went type annotation -> constant folding -> type analysis instead of the current type annotation and analysis -> constant folding as it would allow us to just read the constant value in a generic way. I've been lobbying for this for a while now, but I must admit that its a lot of work with low priority. It could also be argued that most modifications to the tree that create new nodes should run in a transform instead of type analysis anyway, and could thus get moved behind the constant folding step. BTW, Pyrex also still uses "result()" in a couple of places during the analysis phase. It's just luckily escaping crashes because integer constants are really just plain string valued C constants there. > after the temp refactoring is complete we'll hopefully remove > result_code from pre-code-generation entirely. Sure thing, a clear 0.12 goal. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
