Closures in Python

Q. 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 [newsgroup] 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.