[Barry, on dynamic scopes] > This is how Emacs Lisp behaves, and it's used all the time in ELisp > programs. On the one hand it's quite convenient for customizing the > behavior of functions. On the other hand, it can make documenting the > interface of functions quite difficult because all those dynamically > scoped variables are now part of the function's API. > > It's interesting to note that many ELispers really hate dynamic > scoping and pine for a move toward lexical scoping. I'm not one of > them. I don't care what you pine for in ELisp, but for Python this would be a bad idea. > I'm not as concerned about "fixing" nested functions because I hardly > ever use them, and rarely see them much in Python code. Fixing > lambdas would be nice, but since Guido considers lambdas themselves a > mistake, and given that lamda use /can/ be a performance hit in some > situations, does it make sense to change something as fundamental as > Python's scoping rules to fix this eddy of the language? I referred to this in our group meeting as "fixing lambda" because that's where others seem to need it most often. But it is a real problem that exists for all nested functions. So let me rephrase that: "fixing nested function definitions" is useful, if it can be done without leaking memory, without breaking too much existing code, and without slowing down code that doesn't use the feature. --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