Guido van Rossum wrote:
Maybe you could just as well make it a plain string literal and call a function that parses it into a parse tree:
expr = parse("x + y*z") assert isinstance(expr, ast.Expression)
The advantage of this approach is that you can define a different language too...
This is more or less what we have now when we pass SQL queries as strings to database engines.
There are numerous problems with this. One of them is the fact that editors have no idea that the code inside the string is code, so they can't help you out with any syntax highlighting, formatting, etc.
Another is that it makes passing parameters to the embedded code very awkward. One of the things I would like to get from a code-as-ast feature is a natural way of embedding sub-expressions that *do* get evaluated according to the normal Python rules. For example, one should be able to write something like
cust = "SMITH" date = today() sales = select(transactions, @ast: customer_code == cust and transaction_date == date)
and have it possible for the implementation of select() to easily and safely evaluate 'cust' and 'date' in the calling environment.