You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the only way to do this is to comment out certain phases of the pipeline. Unfortunately, some of the optimization phases are necessary and/or change the semantics of the code (or result in broken compiles). This should be fixed.
It would be quite simple to give somewhat abstract names to each of the optimisations (e.g. "iteration.string", "iteration.enumerate", "control.inlist", "builtin.all", "builtin.list.append") that are easy to map to methods in the optimisation transform classes. That way, we could simply intercept the dispatchers in these classes and check if the optimisation was explicitly disabled. We could also support wildcards like "list.*".
Most of the "feature implementations" that currently live in Optimize.py are just special cases of unimplemented features (e.g. all(genexp) while lacking generator expressions in general). Or think of slicing pointers, which doesn't work anywhere outside of iteration (see e.g. the carray iteration transform method). It's clear that these things break the compilation when being disabled, so we might want to exclude them from the enable/disable mechanism.
Currently, the only way to do this is to comment out certain phases of the pipeline. Unfortunately, some of the optimization phases are necessary and/or change the semantics of the code (or result in broken compiles). This should be fixed.
Migrated from http://trac.cython.org/ticket/565
The text was updated successfully, but these errors were encountered: