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.