[Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

Benjamin Peterson benjamin at python.org
Sat Mar 12 04:01:47 CET 2011

2011/3/11 Raymond Hettinger <raymond.hettinger at gmail.com>:
> Today, there was a significant check-in to the peephole optimizer that I
> think should be reverted:
>                http://hg.python.org/cpython/rev/14205d0fee45/
> The peephole optimizer pre-dated the introduction of the abstract syntax
> tree.  Now that we have an AST, the preferred way to implement additional
> optimizations is with AST manipulation, upstream from code generation.  This
> approach is faster and much more reliable than the more brittle approach
> of disassembling, analyzing, and rewriting the bytecode created by the
> compiler.

The problem is no such AST optimizer exists. It's one thing avoid
changing old code because an improved version is in the works or
available (say argparse in lieu of getopt) and quite another when no
replacement code exists. At the moment, there is little reason not to
accept progressive improvements (with sights on overall design as
usual) to the code.

IMO, Ast or not ast statically optimizing python in any meaningful way
is a impossible task anyway. So, a better solution would be to just
rip the thing out.

> There should no longer be any significant changes to the existing
> optimizer.  It took a good deal of care to get it right in the first place.
>  The code is stable and has been proven successful by many years of
> deployment.  The nature of the peephole optimizer  is that changes to it are
> high risk, that the procedure is brittle, and that it is easily mucked-up in
> ways that are hard to detect. Accordingly, we've kept to simple conservative
> transformations and have assiduously avoided more complex (and interesting)
> optimizations.

Can you point to examples where changes introduced long-term
instability? ISTM, that the peepholer is one of the better tested
parts of the interpreter if not directly from its own tests, from
running the entire stdlib tests.

> FWIW, I've been the maintainer (as well as the original designer and
> implementer) of the peephole optimizer from the beginning; however, today's
> committer did not accept my advice to be very conservative with changes to
> it and to strongly prefer AST transformations instead.  Please consider
> reverting this change.


More information about the Python-Dev mailing list