[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