Jeremy Hylton wrote: > > >>>>> "MAL" == M -A Lemburg <mal@lemburg.com> writes: > > MAL> It may not look serious, but changing the Python lookup scheme > MAL> is, since many inspection tools rely and reimplement exactly > MAL> that scheme. With nested scopes, there would be next to no way > MAL> to emulate the lookups using these tools. > > Can you say more about this issue? It sounds like it is worth > discussing in the PEP, but I can't get a handle on exactly what the > problem is. Any tool needs to implement or model Python's name > resolution algorithm, call it algorithm A. If we change name > resolution to use algorithm B, then the tools need to implement or > model a new algorithm. I don't see where the impossibility of > emulation comes in. Well first you'd have to change all tools to use the new scheme (this includes debuggers, inspection tools, reflection kits, etc.). This certainly is not a smart thing to do since Python IDEs are just starting to appear -- you wouldn't want to break all those. What get's harder with the nested scheme is that you can no longer be certain that globals() reaches out to the module namespace. But this is needed by some lazy evaluation tools. Writing to globals() would not be defined anymore -- where should you bind the new variable ? Another problem is that there probably won't be a way to access all the different nesting levels on a per-level basis (could be that I'm missing something here, but debugging tools would need some sort of scope() builtin to access the different scopes). I'm not sure whether this is possible to do without some sort of link between the scopes. We currently don't need such links. -- Marc-Andre Lemburg ______________________________________________________________________ Business: 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