Hi, Robert Bradshaw wrote: > On Mar 15, 2008, at 3:34 AM, Stefan Behnel wrote: > >> Hi, >> >> as I suggested before, I think it would be helpful if plugins could >> tell the >> compiler directly when they were to run (without the current -T >> option). I >> think there would at least be an analysis step in addition to the >> existing >> tree processing step for the plugin lifecycle, but the plugin might >> also need >> to run at different times of the compiler lifecycle, and treat different >> syntax structures. I see the following lifecycle hooks here: >> >> - pre analyse types >> - post analyse types > > - post type conversion phase?
Sure, good catch. >> - pre generate code >> - post generate code > > What would happen in this last one? Assuming that plugins are called during the tree traversal, the first would output code before the normal code generated for the node, and the second would add code behind it. Think of it as a very simple form of AOP join points. >> I would suggest mapping these to method names in the plugins. You >> could then write >> >> class MyTransform(Transform): >> def pre_analyse_types(self, node, name): >> ... >> >> instead of the current "process_node()" method. > > I think process_node offers more flexibility of phases, which may > change/become more granular later on. Some transforms may need to know > what the current phase is though. As Dag suggested, we could let a plugin register its transformations for specific phases. That makes it more general and explicit enough. >> I could also imagine keeping a set of node types in the plugin that >> would be >> used for selecting appropriate transformations for the current node. >> In the >> transformation example, there is this line >> >> if isinstance(node, Nodes.ForInStatNode) ... >> >> that determines when to run the plugin. If the plugin provided a set of >> interesting nodes instead, the infrastructure could store them in a dict >> (mapping node types to a list of plugins) and directly select the >> transformations that can run on that node. Question in that case: how >> to deal >> with subtypes? Would they be expected to match? Or should the plugin just >> specify all node types, including their expected subtypes? > > Perhaps. One would have to come up with a reasonable way to filter > things. The current approach seems the simplest way to get something up > and running. I'm fine with that - but not with the '-T' command line option: a) it doesn't work with distutils and b) it would be stupid to require users to take case that transformations run in the right phase. Activating/deactivating plugins is ok, but the configuration must be an explicit part of the plugin itself (be it code or declaration). Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
