There was a bit of discussion on the python-3000 list about getting access to AST, and the manipulations one could do at that point. Several people chimed in; I wrote up several packages I know of that could make use of this:

• ORMs:

  • Dejavu by Robert Brewer 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 can imagine an RDF querying system that would work similarly, but not using SQL

• Constraints:

  • RuleDispatch compiles strings and then looks inside their AST, 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

• Numeric, etc...

  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 an equation solver was noted

Underlying this vaguely-defined feature is the same featureset as LINQ, and it's something that people have been doing in Python for some time despite the fact that the language doesn't support it particularly well. It would be in my personal top 3 features that I'd like to see in py3k.

Guido's reply was:

I believe I've seen something like this described for an experimental version of Haskell; they had an operator that you used to prefix an expression and it returned the AST for that expression. One important feature was that they also had the opposite feature -- you could use another operator in the thus-quoted expression and it would evalulate that subtree and a normal expression, and substitute the result in the tree. They probably used it to implement a macro facility (though the example I remember was a type-safe printf facility).

I'm going to place the ball firmly in the court of those who want this feature: please write a proposal and an implementation. All that work is not going to get your proposal accepted for certain, but it'll let me look at it.

(You know, I really hate to be in the position of the parent always saying "no". But there's gotta be someone who ensures that Python 3000 will in fact be Python 3000 and not Perl 7. There are many, many more possible changes to the language than can possibly be accepted. We have to prioritize.)

So, the challenge is out. In order to put this feature up for consideration:

• We have to agree what it is, what problems it solves
• An interface
• An implementation
• A justification/PEP
• Tests, both for the implementation and the justification

So: if you are interested in this sort of feature, please pop on over to the python-3000 list so we can discuss it (that list seems like the best place to discuss, unless someone suggests otherwise).