Jeremy Hylton wrote: > > MAL> Better issue a warning than raise an exception here ! > > TP> If Jeremy can't generate correct code, a warning is too weak. > > MAL> So this is the price we pay for having nested scopes... :-( > > TP> I don't know. It apparently is the state of the code at this > TP> instant. > > The code is complaining about 'from ... import *' with nested scopes, > because of a potential ambiguity: > > def f(): > from string import * > def g(s): > return strip(s) > > It is unclear whether this code intends to use a global named strip or > to the name strip defined in f() by 'from string import *'. The right thing to do in this situation is for Python to walk up the nested scopes and look for the "strip" symbol. > It is possible, I'm sure, to complain about only those cases where > free variables exist in a nested scope and 'from ... import *' is > used. I don't know if I will be able to modify the compiler so it > complains about *only* these cases in time for 2.1a2. Since this is backward compatible, wouldn't it suffice to simply use LOAD_GLOBAL for all nested scopes below the first scope which uses from ... import * ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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