[Python-ideas] Python-ideas Digest, Vol 90, Issue 30

[Ned Batchelder]

On 5/21/14 8:17 PM, Eric Snow wrote:
>>> * Over time, I expect that some of the functionality of the peepholer
>>> >>is going to be moved upstream into AST transformations you will
>>> >>have even less ability switch something on-and-off.
>> >
>> >I'm perfectly happy to remove the word "peephole" from the feature.  If we
>> >expect the set of optimizations to grow in the future, then we can expect
>> >that more cases of code analysis will be misled by optimizations.  All the
>> >more reason to establish a way now that will disable all optimizations.
> While the use-case is very specific, I think it's a valid motivator
> for a means of disabling all optimizations, particularly if disabling
> optimizations is isolated to a very focused location as you've
> indicated.
>
> The big question then is the impact on implementing optimizations (in
> general) in the future.  There has been talk of AST-based
> optimizations.  Raymond indicates that this makes it harder to
> conditionally optimize.  So how much harder would it make this future
> optimization work?  Is that a premature optimization? <wink>
>
I don't understand the claim that AST transformations will have less 
ability to switch something on-and-off.  The very term "AST 
transformations" outlines the implementation: step 1, construct an AST; 
step 2, transform the AST; step 3, generate code from the AST. My 
proposal is that a switch would let you skip step 2.

This is analogous to the current optimizer, which generates bytecode, 
then as a separate (and skippable!) step, performs peephole 
optimizations on that bytecode.

--Ned.