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

Ian Bicking ianb at colorstudy.com
Mon Apr 10 19:52:00 CEST 2006


Greg Ewing wrote:
> Robert Brewer wrote:
>> Part of the benefit of the bytecode-hacking is that your expression 
>> never has to be in a string.
> 
> I'm wondering whether there should be some kind of
> "code literal" syntax, where you write a Python
> expression and the compiler transforms it as far
> as the AST stage, then makes it available to the
> program as an AST object.

I also would really like this.  There's a few projects I see that could
use this now:

Several ORMs.  Dejavu (Robert's ORM) does lambda introspection.
SQLObject and SQLAlchemy use operator overriding, which isn't as general
but is used to similar effect.  SQLComp by Peter Hunt is another lambda
introspection library.  I bet a non-SQL RDF system could benefit from
the same thing.

RuleDispatch compiles strings, maybe a bit fancier than the other
projects, as I believe the other's don't pay as much attention to the
scope at the position where the expression is defined.  I believe
Enthought's Traits is doing something vaguely similar (at least in
motivation, at some level), using constraints.  David Binger did a
lightning talk on a system he wrote -- who's name I've forgotten --
which is also constraint-based and could benefit from a way to represent
constraints.

I think the various numeric packages do things along these lines, often
with operator overloading and whatnot, so that you can give an
expression that is efficiently implemented in a specific context.  This
is similar in spirit to what the ORMs are doing, except where the ORMs
use the expression to generate SQL to be sent off somewhere, the numeric
packages consume the expression in-process (but not in Python).

In another email equation solvers were also suggested.

Guido noted you can do this with operator overloading, but while that
certainly does work I think we should have something better than that in
Python.  It also fails for the operators "and", "or", "not", "in", "is",
and maybe some others I can't think of right now.

So... in summary, I think there's a bunch of consumers already out
there, but we could all use something a little more formalized.  And
maybe a little syntactic support; kludging expressions into lambdas
doesn't look that pretty or make it at all clear what's going on.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the Python-3000 mailing list