[GvR] >Note that Jeremy has a new Python compiler package (Lib/python/ in the >Python 2.3 CVS tree), which currently uses parse trees as produced by >the old 'parser' module as input, and then restructures them into more >abstract syntax trees. This compiler is easily retargetable to other >input and output structures though -- I believe Finn Bock already has >a Jython version of it. I don't know what it generates, I doubt it >generates CPython bytecode, maybe it generates Java source or JVM >assembler; I believe it takes the same parse tree that Jython uses as >input. yup, it is more than a prototype, the compilers in the current Jython CVS are based on that. >I think it would be useful if you use the same form of abstract syntax >trees as Jeremy's parser uses (not the parser module output, but the >restructured abstract syntax trees); I think they are quite flexible >and useful. Yup and the point of the exercise is to make possible for the future versions of PyChecker etc to work with Jython too. >If you don't want to do this, you'll have to motivate why your >alternative is better, and also show how Jeremy's compiler package can >be easily adapted to use your form of parse trees. yes ideally it should output a superset of that, or something with small changes that can be easely backported to the above effort in Jython, otherwise is a kind of step backward: when first proposed the PEP would have been a furher blessing for the awful parser module output format, now the efforts of Jeremy and Finn have moved a bit both Python and Jython away from that and on a parallel track. regards.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4