GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • [ date ]
  • [ thread ]
  • [ subject ]
  • [ author ]

This view

  • Original page
  • New address

GeezerVison is showing mail.python.org — [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?

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

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

  • Previous message: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
  • Next message: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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 "<stdin>", line 1, in ?
  File "<stdin>", 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

  • Previous message: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
  • Next message: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the Python-Dev mailing list
You are visitor 01402520 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.