[Python-ideas] For-loop variable scope: simultaneous possession and ingestion of cake

[Dillon Collins]

On Friday 03 October 2008, Bruce Leban wrote:
> On Fri, Oct 3, 2008 at 6:00 PM, Dillon Collins <dillonco at comcast.net> wrote:
> > On Friday 03 October 2008, Greg Ewing wrote:
> > > My next step would be to propose a 'let' statement
> > > for dealing with things like that:
> > >
> > >    for i in range(3):
> > >      let j = str(i):
> > >        funs.append(lambda: j)
> >
> > Well now, that seems more than a little ridiculous.  If we're going to be
> > creating a keyword that rescopes variables, why not just use that instead
> > of
> > messing with the for loop.
>
> I don't see how this is messing with the for loop at all.

The original proposal is that the for loop create a local scope for it's 
variable and those created within it.  That's what I was referring to; the 
let statement itself obviously doesn't.  The point being that if we're going 
to make a scoping keyword, why add implicit scoping to for loops as well.

>
> > Seems like that would be a generally more useful
> > solution anyway.
> >
> > Perhaps instead:
> >
> > for i in range(10):
> >     j = str(i)
> >    scope i, j:
> >        funs.append(lambda: (j,i))
>
> The difference between my or Greg's proposal is that the scope of the
> variable is the inner block while your proposal the variable has two
> scopes. That is, to annotate the code:
<snip examples>
> I don't care for the fact that there are really two k variables here (or
> more properly N+1). Also, the implicit copying sort of obscures some
> details. The fact that my alternative requires explicit setting of the
> value of the scoped variable is a good thing.

If you look at the original proposal for this thread:

"Upon exiting the loop, the final value of the loop variable is copied into 
the surrounding scope"

So we are already dealing with at least one implicit copy.  This is why I 
think that the loop scoping suggestion should basically be dropped in favor 
of some sort of scope block.

> For example, consider this:
>
>   a = [0,1,2]
>   for i in range(3):
>     scope a:
>       a.append(i)
>       ... lambda: ... a ...
>
> Yes, a is in a different scope, but references the same list so the scope
> is useless. At least in my or Greg's version, since you have to assign to
> the local variable, there's a clear place where you can see the copying is
> missing.

I consider that an advantage.  Throughout all the rest of Python we deal with 
the concepts of variable assignments and mutable objects.  Things like 
default arguments, global variables, and scopes (particularly prior to 
nonlocal).  Why should scoping be any different? 

>   'local' var [ '=' expr ] ( ',' var [ '=' expr ] )* ':'

While I like it conceptually, as I said above I don't really see the value in 
requiring assignment.  If you did, you'd see "local a=a:" most of the time.  
Then, in a few months, someone will say that it's unnecessarily verbose/kind 
of confusing and post on this list a suggestion that "local a:" be equivalent 
to "local a=a:"