<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>RE: [Python-3000] AST access (WAS: Adaptation vs. Generic Functions)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Guido van Rossum wrote:<BR>
> On 4/9/06, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:<BR>
> > Robert Brewer wrote:<BR>
> > > Part of the benefit of the bytecode-hacking is that<BR>
> > > your expression never has to be in a string.<BR>
> ><BR>
> > I'm wondering whether there should be some kind of<BR>
> > "code literal" syntax, where you write a Python<BR>
> > expression and the compiler transforms it as far<BR>
> > as the AST stage, then makes it available to the<BR>
> > program as an AST object.<BR>
> ><BR>
> > Or would that be too close to "programmable<BR>
> > syntax" for Guido's liking?<BR>
><BR>
> I'm more concerned about the choice of AST data structure<BR>
> and how it affects IronPython, PyPy, Jython and possible<BR>
> other Python implementations. I'd like to keep both the<BR>
> AST and the bytecode spec out of the language spec,<BR>
> otherwise those implementations will face the tough choice<BR>
> of either changing their parser technology to one that<BR>
> is probably less suited, or implementing two full parsers.<BR>
<BR>
Not to mention cross-version issues with persisted AST objects or bytecode-sequences. When pickling my Expression objects, I chose to decompile them back into Python code for that reason. Although I had to upgrade the decompiler between 2.3 and 2.4 (to allow for the JUMP target changes, for example) I didn't have to upgrade a single saved Expression object.<BR>
<BR>
<BR>
Robert Brewer<BR>
System Architect<BR>
Amor Ministries<BR>
fumanchu@amor.org</FONT>
</P>
</BODY>
</HTML>