[Python-Dev] closure semantics

Samuele Pedroni pedronis at bluewin.ch
Fri Oct 24 12:46:42 EDT 2003


At 09:05 24.10.2003 -0700, Guido van Rossum wrote:
> > well, no, it's probably that I expect rebindable closed-over vars to
> > be introduced but some kind of structured construct instead of the
> > usual Python freeform.
>
>Why does rebindability make a difference here?  Local vars are already
>visible in inner scopes, and if they are mutable, they are already
>being modified from inner scopes (just not rebound, but to most
>programmers that's an annoying detail).

most Python programmers or most Python programmers using closures?

Well, it's a gut feeling, let's try to articulate it. Because

a) parametrizing a closure with some read-only variable
b) possibly shared mutable state with indefinite extent

are very different things. I think that people should recur to b) instead 
of using classes sparingly and make it clear when they do so.

b) can feel like global variables with their problems, I think that's why I 
would prefer a syntax that still point out: this is some state and this are 
functions to manipulate it. Classes are fine for that, and knowing that it 
is common style/idiom in Lisp variants this is also fine there:

  (let ... introduces vars
      ... function defs)

I think it is also about expectations when reading some code. Right now, 
reading Python code I expect at most to encounter a), although b) can be 
obtained using mutable objects, but also in that case IMHO an explicit 
uniform idiom would be preferable, like some Ref object inspired by ML 
references.

I can live with all solutions, although I'm still unconviced apart from the 
Scheme textbook argument (which was serious) that this addition is really 
necessary.

regards. 




More information about the Python-Dev mailing list