> 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. I've seen a Komodo demo. Yes, it does this. But it's soooooooo far from being done that adding this wouldn't really slow them down much, I think. More likely, the toolmakers will have fun competing with each other to be the first to support this! :-) > 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 ? I think globals() should return the module's __dict__, and the global statement should cause the variable to reach directly into there. We'll need to introduce a new builtin to do a name *lookup* in the nested scopes. > 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. Correct. That link may have to be added to the frame object. --Guido van Rossum (home page: http://www.python.org/~guido/)
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