[Python-Dev] Optimization of Python ASTs: How should we deal with constant values? (original) (raw)

Adam Olsen rhamph at gmail.com
Fri May 9 03:38:29 CEST 2008


On Thu, May 8, 2008 at 5:54 PM, Thomas Lee <tom at vector-seven.com> wrote:

Adam Olsen wrote:

On Thu, May 8, 2008 at 5:22 PM, Thomas Lee <tom at vector-seven.com> wrote:

Nick Coghlan wrote:

There are a lot of micro-optimisations that are actually context independent, so moving them before the symtable pass should be quite feasible - e.g. replacing "return None" with "return", stripping dead code after a return statement, changing a "if not" statement into an "if" statement with the two suites reversed, changing "(1, 2, 3)" into a stored constant, folding "1 + 2" into the constant "3". I believe the goal is to see how many of the current bytecode optimisations can actually be brought forward to the AST generation stage, rather than waiting until after the bytecode symtable calculation and compilation passes.

That's been the aim so far. It's been largely successful with the exception of a few edge cases (most notably the functions vs. generator stuff). The elimination of unreachable paths (whether they be things like "if 0: ..." or "return; ... more code ...") completely breaks generators since we might potentially be blowing away "yield" statements during the elimination process. Also breaks various sanity checks relating to the global statement. What sanity checks are these exactly? Is this related to the lnotab?

Here we are. In 2.4.4:

def foo(): ... print test ... if 0: ... import test ... foo() Traceback (most recent call last): File "", line 1, in ? File "", line 2, in foo NameError: global name 'test' is not defined

2.5.1 correctly raises an UnboundLocalError instead.

Searching the bug DB for old bugs involving the optimizer showed several variations on this, such as "if 0: yield None" at module scope not raising a SyntaxError (Issue 1875, still open in trunk). Clearly there needs to be a general approach to avoid affecting these checks with optimizations.

-- Adam Olsen, aka Rhamphoryncus



More information about the Python-Dev mailing list