[Python-3000] AST access (WAS: Adaptation vs. Generic Functions)

Phillip J. Eby pje at telecommunity.com
Mon Apr 10 19:20:41 CEST 2006


At 08:39:36 PM 4/10/2006 -0700, "Guido van Rossum" <guido at python.org> wrote:
>On 4/10/06, Talin <talin at acm.org> wrote:
> > I have a rather odd use case for this. A while back, I decided I wanted to
> > write an algebraic solver, similar to what Mathematica does, except that
> > I wanted to write it in Python. Not just implement it in Python, but have
> > Python be the language in which the rules of formula manipulation were
> > expressed.
>[...]
> > You can immediately see the problem - since I don't have syntactical
> > support, I have to manually enter in the expression in an AST-like form,
> > which is clumsy to say the least.
>
>I've seen other packages like this (for different solvers) that solved
>this by overloading various operators to produce a parse tree. All you
>need is some primitive objects named X, Y, Z etc. and then X**2+Y**2
>produces the appropriate parse tree.  Then the analyzer can walk the
>parse tree.

I tried doing something like this when I was writing RuleDispatch, and gave 
up in disgust because there's no sane way to implement "and" and "or" 
operations with this approach.  The bitwise operators (&, |, and ~) bind 
too tightly to be used with comparison expressions, so doing something like 
"x>y & z" would mean "x>(y&z)" instead of "(x>y)&z".  Plus, since there are 
no "symbol" literals, you end up having to do something like "(_.x > _.y) & 
_.z" which looks thoroughly hideous.  (The genexp to SQL use case has 
similar issues, since booleans are needed there as well.)

So, since beautiful is better than ugly, I switched to parsing Python code 
in a string.  As ugly as it is to bury the beautiful Python code in quotes, 
it's far better than writing some kind of hideous pseudo-Python outside of 
quotes.

Even if you don't want to provide a writable func_ast attribute, it would 
be wonderful if there was some sort of "AST literal" syntax, especially 
since it would also address the request for a symbol syntax.  (That is, an 
AST literal for a name could be used as a symbol, with no need to invent a 
separate symbol syntax.)

Maybe in Python 3K the backquote could be used to quote code in some way, 
since we won't be using it for repr() anymore.  :)

So if you could backquote code to make an AST literal, you could spell 
RuleDispatch overrides like:

     @pprint_when(`isinstance(ob,list) and len(ob)<10`)
     def pprint_short_list(ob):
         ...

And the database query use case could be done using something like:

    db.query(`(row for row in some_table if row.x>42)`)"

And of course the symbol processing example is similar.

Perhaps the backquote isn't the right character for this; I do seem to 
recall you commenting once that the backquote was a mistake because of 
issues with printing, fonts, etc., as far as not being distinguishable 
enough from the forward quote.  But the basic idea would still be useful 
with some other way to spell an AST literal.



More information about the Python-3000 mailing list