guido at python
Aug 13, 2012, 7:45 AM
Post #26 of 32
Not so fast. If you make this a language feature you force all Python
implementations to support an identical AST API. That's a big step.
Not that AST manipulation isn't cool -- but I'd like to warn against
over-enthusiasm that might backfire on the language (or its community)
as a whole.
On Mon, Aug 13, 2012 at 1:34 AM, Mark Shannon <mark [at] hotpy> wrote:
> Brett Cannon wrote:
>> On Sat, Aug 11, 2012 at 8:16 PM, Eric Snow <ericsnowcurrently [at] gmail
>> <mailto:ericsnowcurrently [at] gmail>> wrote:
>> On Sat, Aug 11, 2012 at 6:03 PM, Brett Cannon <brett [at] python
>> <mailto:brett [at] python>> wrote:
>> > It would also be very easy to expand importlib.abc.SourceLoader
>> to add a
>> > method which is called with source and returns the bytecode to be
>> > out
>> Yes, please. Not having to hack around this would be nice.
> AST transformation is a lot more general than just optimization.
> Adding an AST transformation is a relatively painless way to add to
> Python the last element of lisp-ness that it lacks:
> Namely being able to treat code as data and transform it at runtime,
> after parsing but before execution.
> Some examples:
> Profiling code be added by an AST transformation.
> IMO this would have been a more elegant way to implement CProfile
> and similar profilers than the current approach.
> AST transformations allow DSLs to be implemented in Python
> (I don't know if that is a + or - ).
> Access to the AST of a function at runtime would also be of use to
> method-based dynamic optimizers, or dynamic de-optimizers for static
> All for the price of adding a single method to SourceLoader.
> What a bargain :)
> Python-Dev mailing list
> Python-Dev [at] python
--Guido van Rossum (python.org/~guido)
Python-Dev mailing list
Python-Dev [at] python