On 4/4/2011 2:00 PM, Guido van Rossum wrote:
On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
<fwierzbi...@gmail.com> wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py to alert me!
[and]
On Mon, Apr 4, 2011 at 10:38 AM, Michael Foord
<fuzzy...@voidspace.org.uk> wrote:
A lot of tools that work with Python source code use ast - so even though
other implementations may not use the same ast "under the hood" they will
probably at least *want* to provide a compatible implementation. IronPython
is in that boat too (although I don't know if we *have* a compatible
implementation yet - we certainly feel like we *should* have one).
Ok, so it sounds like ast is *not* limited to CPython? That makes it
harder to justify changing it just so as to ease the compilation
process in CPython (as opposed to add new language features).
Harder, but not impossible. Moving optimizations from bytecode (where
they are demonstrably a bit fragile) to ast manipulations (where we
presume they will be more robust and can be broader) should be a win in
itself and it also makes them potentially available to *other*
implementations. (There would have been some advantage to making this
change for 3.0 But there was also reason for as little change as needed,
just as with unittest.)
Are at least some of the implementation methods similar enough that they
could use the same AST? It is, after all, a *semantic* translation into
another language, and that need not depend on subsequent transforation
and compilation to the ultimate target. A multiple-implementation AST
could still be x.y dependent.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
