Steve Holden wrote:
> While not strictly related to the global statement, perhaps Adam refers
> to the possibility of optimizing away code with an assignment which
> would make a name be recognized as local? If you're worried about
> "yield" disappearing you should also be worried about assignments
> disappearing, since that might cause names to be interpreted as globals.
And once you start annotating functions as generators or not, and
variable names as locals or cell variables or globals, you're starting
to build up a substantial fraction of the information that is already
collected during the symtable construction pass.
Perhaps the initial attempt at this should just focus on identifying
those operations which have the potential to alter the results of the
symtable construction, and leave those to the bytecode optimisation step
for the moment. Doing the symtable pass twice seems fairly undesirable,
even if it does let us trim some dead code out of the AST.
Cheers,
Nick.
P.S. Here's a nonsensical example where optimising away the dead code
after the return statement would significantly change the code's semantics:
>>> def silly():
... def inner():
... print cell_var
... return inner
... cell_var = None
...
>>> silly()()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in inner
NameError: free variable 'cell_var' referenced before assignment in
enclosing scope
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4