December 2006

From the newsgroup:

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.