Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: Why do closures do this?
Date: Sun, 28 Aug 2011 12:26:18 -0400
References: <20110828134505.795cd32b8fc5ccc472f85ae3@johnohagan.com> <4E5A4B08.2050405@jollybox.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
In-Reply-To: <4E5A4B08.2050405@jollybox.de>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.507.1314548832.27778.python-list@python.org>
Lines: 43
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:12344

On 8/28/2011 10:04 AM, Thomas Jollans wrote:

> This does not do what you'd like it to do. But let's assume that, it
> did, that Python, when encountering a function definition inside a
> function, "froze" the values of nonlocal variables used in the new
> function, from the point of view of that function =E2=80=94 that *might=
* be more
> intuitive, at least in certain situations. However, what if you wanted =
a
> closure to access a nonlocal variable that changes - acting differently=

> depending on what has since happened in the parent function.
>
> That may not be as common, but it is a perfectly plausible situation,
> and the hack required to support that behaviour in a Python that acts a=
s
> you had expected it to, a surrogate namespace using a class, list, or
> dict, is infinitely more cryptic and ugly than the default-parametre ha=
ck.

Or, what if the nonlocal name is not even defined when the closure is.

 >>> def f():
	def g(): print(a)
	a =3D 3
	g()

 >>> f()
3

Note that global names also do not have to be defined when a function=20
using them is compiled. The current situation is that nonlocal and=20
global names are treated the same way. This makes normal and nested=20
functions as much the same as possible. This is intentional. It would be =

extremely disconcerting if moving code that contains a def into or out=20
of a wrapping function radically changed its behavior more than is=20
absolutely necessary.

--=20
Terry Jan Reedy