> On Sep 19, 2009, at 10:45 , Dag Sverre Seljebotn wrote: > >> Magnus Lie Hetland wrote: > [snip] >>> IOW, I could just strip down the Cython code to get plain Python >>> equivalents that I could use the dev-tools on. Is that just a silly >>> idea? Would I be better off with pure mode? (Is there, perhaps, >>> such a beast/processor somewhere? I'm assuming I could reuse the >>> Cython parser if I needed to write something myself?) >> >> No, it's a good idea (though see below). The work is about 1/3 done >> I think... Compile/CodeWriter.py contains a tree transform which >> will serialize the tree back to Cython code which should be a good >> starting point (it only supports parts of the language currently >> though) -- it can simply have a flag or subclass to skip any type >> declarations, output cdef classes as py classes etc. > > Sounds great :) (I found it in Cython/Writer.py, though; I guess > perhaps it's been moved in the devel version or something?) > >> To quickly test with it, plug an instance into the pipeline (search >> for "pipeline" in Main.py). > > Hmm. I've been experimenting with this for a while now, and I'm a bit > stumped. > > After fiddling about with using various classes from Visitor.py as mix- > ins to get CodeWriter to fit into the pipeline, I just added a simple > __call__ myself. However, it seems that somehow the results in the > LinesResult disappear somewhere along the pipeline? At the moment, I > simply print them out before returning form __call__ :-/
I must be brief... Yes that's as intended, otherwise you'd disturb the pipeline. > As for the pipeline -- is it OK to just put it right after the parsing? Seems like the best location, yes. analyse_declarations tends to remove some of the type declarations for you, but it is probably easier (and more stable with regards to refactorings in Cython etc.) to strip these explicitly (= not ouput) in the writer. > For one thing, I get lots of unhandled nodes, but I guess that's just > because they're not implemented yet. But I also get the transformation Yep. > from "import numpy as np" to "np = (import numpy)", which isn't > exactly valid :-> (I guess that's not an issue with the stage of the > pipeline, though; probably not something that'll be get more > Pythonesque further down the line toward code generation ;-) No, unfortunately it is the opposite: The parser is too smart for its own good and does some transformations (we internally treat an import as the latter case, so it is already transformed too far). Correct solution: Submit a patch which make the parser leave import statements alone (probably through a new ImportStatNode, in contrast with the current which is more like a ImportExprNode). Then, in ParseTreeTransforms.PostParse, transform ImportStateNode to ImportExprNode, and insert your writer before PostParse in the pipeline. > >> (If a proper tool is developed one should set up a seperate pipeline >> for the tool. In the devel branch I have been doing some >> refactorings so that there's a seperate Pipeline.py.) > > > Hm. OK. I guess in my case, it'd be useful to plug this thing into the > pipeline set up by distutils, so that when I build the C code etc., I > also get .py files in some configured directory. But perhaps there can > be parallel pipelines based on the same parse tree? > > -- > Magnus Lie Hetland > http://hetland.org > > > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
