On Sat, Jan 23, 2016 at 4:57 AM, Stefan Krah <skrah.temporarily@gmail.com> wrote:
I've never liked the use of "late binding" in this context. The behavior is totally standard for closures that use mutable values.
I wonder if the problem isn't that "binding" is a term imported from a different language philosophy, and the idea there is just fundamentally different from Python's philosophy about variables. In Python, a variable is *conceptually* just a key in a dict (and often, like for globals, builtins and instance or class variables, that really is how it's implemented). The variable name is the key, and there are implicit (and often dynamic) rules for deciding which dict to use. For local variables this is a bit of a lie, but the language goes out of its way to make it appear true (e.g. the existence of locals()). This concept is also valid for nonlocals (either the implicit PY2 kind, of the explicit PY3 kind introduced by a nonlocal statement). The implementation through "cells" is nearly unobservable (try getting a hold of a cell object through introspection without using ctypes!) and is just an optimization. Semantically (if we don't mind keeping other objects alive loger), nonlocals can be implemented by just holding on to the stack frame of the function call where they live, or, if locals hadn't been optimized, holding on to the dict containing that frame's locals would also work. So, I don't really want to introduce "for new x in ..." because it suddenly introduces a completely different concept into the language, and it would be really hard to explain what it does to someone who has correctly grasped Python's concept of variables as keys in a dict. What dict hold x in "for new x ..."? It would have to be considered a new dict created just to hold x, but other variables assigned in the body of the for loop would still be in the dict holding all the other locals of the function. Bah. -- --Guido van Rossum (python.org/~guido)