- Author: DagSverreSeljebotn
- Status: Idea
- See also: [:enhancements/parsetreetransforms: Code tree transforms]
There seems to be no disagreement that this needs to happen within the Cython community, it seems that most people have reached the same conclusion that this refactoring needs to be done in order to move the project forward.
Currently, Cython operation is to first parse the text into a tree, and then call recursive methods in the tree that gradually takes it to the state that is finally serial. Thus every kind of node (for instance a EqExprNode (TODO: Find real name) containing a comparison happening with ==) contains code for figuring out if there is a compile-time value, finding out which type the resulting expression is, dumping C code, and so on.
When writing new transforms the best place is usually in-between these two: You want to know the types of the variables etc. on which you are operating, but you also want coercion to happen on the code that you insert in the tree yourself (and avoid having to deal with already inserted coercion nodes cluttering the tree).
The problem is that these two changes in the tree currently happen in the same recursive chain of function call on the nodes. There is no need for these to happen in the same chain, they just do for historic reasons.
So this subproject is about refactoring the code split the two phases up - probably by creating a new transform using the new transform framework doing the coercion and remove the coercion from the original source.
Since this is potentially very dangerous, good regression tests are essential. As the output shouldn't change, this can be done simply by checking that Cython produces the same output for lots of code before and after the change (preferably code with lots of automatic conversion in it).