When Closure get external variable's value?

[Fredrik Lundh]

Huayang Xia wrote:

> I don't understand why while a nested function perfectly matches the
> definition of closure, it is not closure simply because it is not used
> by external world.

Like so many other computing terms, the word "closure" is used in 
different ways by different people.

Strictly speaking, a closure is simply a function with free variables, 
where the bindings for all such variables are known in advance.  Some 
early languages didn't have "closed" functions; the bindings for free 
variables were left open, and was determined at runtime.  And languages 
that had both "open" and "closed" functions needed some way to 
distinguish between the two, so people started referring to the latter 
as "closures".

But in Python, as well as in most other modern languages, all functions 
are "closed" -- i.e. there are no "open" free variables -- so the use of 
the term has morphed from "a function for which all free variables have 
a known binding" to "a function that can refer to environments that are 
no longer active" (such as the local namespace of an outer function, 
even after that function has returned).  And since *that* is somewhat 
difficult to implement, and programmers don't like to hide things that 
are hard to implement, people still like to use the term to distinguish 
between closed functions of kind 1 and closed functions of kind 2.  As 
in this thread, they sometimes argue that when you're using a closed 
function of kind 2 in a specific way, it's not quite as much of a 
closure as when you use it in another way.  Heck, some people even argue 
that languages that don't support closed functions of kind 3 (a kind 
that Python currently doesn't support) don't really have closures at all.

But as a language user, you can actually forget about all this -- all 
you need to know is that in Python, all functions are closed, and free 
variables bind to *variable names* in lexically nested outer scopes.

</F>