Aahz wrote:

You'll need to make sure that exceptions don't break this.

Good point. I think that can be addressed by wrapping the final value copying in a finally block. That will ensure that the final value is always decoupled from anything captured by a nested function. -- Greg

Andrew Clover wrote:

Greg Ewing wrote:

...

1. If the loop variable is referenced by such a nested function, a new local scope is effectively created to hold each successive value of the loop variable.

Why only the loop variable? What about:

>>> for i in range(3): ... j= str(i) ... funs.append(lambda: j) >>> funs[0]() '2'

Spanking good point. To hack this "properly" all cell variables closed over within the loop would have to go into the per-iteration scope.

It seems an odd sort of scope that lets rebindings inside it fall through outwards.

True, but a lot of Python programs would depend on this - even new ones because of social inertia.

...

Also, most other languages which have lexical scoping and first-class functions don't seem to suffer from problems like this.

That's not always because of anything to do with introducing scopes though. Some of those languages can bind the variable value early, so if you were to write the equivalent of:

>>> i= 3 >>> f= lambda: i >>> i= 4

f() would give you 3. I would love to see an early-value-binding language with similar syntax to Python, but I can't see how to get there from here.

Python could close over the values rather than a cell. That's *almost always* what people really care about anyway! It'd break almost no code. Of course, to satisfy Paul Graham, there'd have to be a way to go back to cells. A "cell" keyword? Other languages make this explicit - they're often called "boxes". I wonder if "nonlocal" could go if there were a "cell" keyword... It wouldn't mean the variable carries pass-by-reference semantics, though. That would be bad. Neil

Greg Ewing wrote:

Neil Toronto wrote:

...

Python could close over the values rather than a cell. That's *almost always* what people really care about anyway! It'd break almost no code.

No, it would break huge amounts of code. Consider

Something we seem to agree on ...

def f(): g()

def g(): print "Gee"

Would you really like to get a NameError or UnboundLocalError on g here?

I believe all (apparently) recursive functions would have the same problem.

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)

The 'let' statement would do the same thing for its variable as the for-loop, but in a one-off fashion.

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. 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))

...

Some of those languages can bind the variable value early, so if

you were to write the equivalent of: >>> i= 3 >>> f= lambda: i >>> i= 4

Can you give me an example of an imperative language that behaves that way? I don't think I've ever seen one.

(Note that the above would be illegal in any functional (i.e. side-effect-free) language, since the syntax doesn't allow you to express rebinding an existing variable.)

How about C? int i; int get(void) {return i;} int main() { i=3; get() i=4; } I think the confusion is the fact that the a local scope is effectively a _global_ scope in locally defined functions. It's really a rather conceptually elegant setup, though a tad confusing. Perhaps that's because we're used to seeing globals as "the global scope" rather than "all encompassing scopes".

On Friday 03 October 2008, Bruce Leban wrote:

On Fri, Oct 3, 2008 at 6:00 PM, Dillon Collins 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:"

On Fri, Oct 3, 2008 at 11:25 PM, Greg Ewing wrote:

I tend to favour 'let' because it has a long history of use in other languages for a very similar purpose, and will be instantly recognisable to anyone familiar with those languages.

If I might suggest that the legacy way is not necessarily the right way, 'let' feels kind of like a variable declaration, while 'scope' or something else (I think I saw 'local' somewhere, which looked okay) would hopefully give more of a notion that there is something deeper going on. I am mostly wary of new users discovering 'let' and using it everywhere because they don't understand what it means. -- Cheers, Leif

Leif Walsh wrote:

If I might suggest that the legacy way is not necessarily the right way, 'let' feels kind of like a variable declaration

It *is* a variable declaration. If you're saying it's not *only* a variable declaration, that's true, but it's also true in other languages that have 'let'.

I am mostly wary of new users discovering 'let' and using it everywhere because they don't understand what it means.

It wouldn't do much harm if they did -- there's no semantic or performance difference if the variable isn't referenced from a nested function. It could even be considered helpful if it makes it clear that a particular temporary variable is only used in a certain region of the code. -- Greg

Greg Ewing wrote: tement, which will be familiar to nobody.

It's true that with a 'let' statement or equivalent, there's no strict need for a change to the for-loop, since you can always say

for i in range(10): let i = i: funcs.append(lambda: i)

But it's an annoying and odd-looking piece of boilerplate to have to use, and in that respect is similar to the existing solutions of inserting another lambda or using a default argument value.

So as a *convenience*, I'm suggesting that the for-loop be given automatic let-like behaviour.

Whereas I consider the proposed automaticity to be a grave inconvenience and confusion factor. What if I *want* a closure to be over variables, as normal, instead of values. It seems to me that what you want is fine-grained control over scoping, or something like that. I would prefer that you overtly propose and argue for some syntax to do that explicitly, instead of sneaking something implicit into for-loops. Or perhaps a different proposal: Def statements close over variables, as currently. Lambda expression close over values, as some people seem to expect them to. This expectation seems to be the crux of the purported 'problem'. This change would also deal with Guido's example. Terry Jan Reedy

Terry Reedy wrote:

Or perhaps a different proposal: Def statements close over variables, as currently. Lambda expression close over values, as some people seem to expect them to.

I don't think it would be a good idea to make defs and lambdas have different behaviour, because they're not interchangeable otherwise. If you're forced to use a def because what you want can't be done in a lambda, you'd be forced to accept different binding behaviour as well. Also, I'm not convinced that people think of defs and lambdas as differing like that. I suspect that they would have the same expectation if a def were written inside the loop instead of a lambda. -- Greg

On Friday 03 October 2008, Greg Ewing wrote:

It's true that with a 'let' statement or equivalent, there's no strict need for a change to the for-loop, since you can always say

for i in range(10): let i = i: funcs.append(lambda: i)

But it's an annoying and odd-looking piece of boilerplate to have to use, and in that respect is similar to the existing solutions of inserting another lambda or using a default argument value.

So as a *convenience*, I'm suggesting that the for-loop be given automatic let-like behaviour.

For what percentage of your for loops will this matter? For me, 0, though I did have one IIRC before I rewrote it. I imagine most people are no different. My point is that it's a lot of added complexity, and possible bugs, gotchas, and performance penalties for an extremely basic part of the language. If we need to have another keyword anyway, why do we need to deal with all that just to save a line in a handful of loops?

The claim was that there exist side-effectful languages with closures that close over values instead of variables. C can't be one of those, because it doesn't even have closures.

Ah, my apologies; I seem to have totally spaced reading the relevant part of the GP.

There is a very simple and efficient way to implement this in current CPython: If the loop variable is referenced by a nested function, it will be in a cell. Instead of rebinding the existing cell, each time around the loop a new cell is created, replacing the previous cell. Immediately before exiting the loop, one more new cell is created and the final value of the loop variable copied into it. [skip] The benefit would be that almost all code involving loops and nested functions would behave intuitively,

+1 from me too. Neil Toronto wrote:

Spanking good point. To hack this "properly" all cell variables closed over within the loop would have to go into the per-iteration scope.

Agreed. And to preserve current semantics these values would need to be copied to the new scope of every next iteration (if it's closed over).

...

It seems an odd sort of scope that lets rebindings inside it fall through outwards.

True, but a lot of Python programs would depend on this - even new ones because of social inertia.

It'll unfortunately have to wait til python 4000 :). I like finally fixing this problem, which I've also run into. But I don't like the idea of introducing a new keyword to create new scopes. I think all variable that are assigned to in a loop body and closed over should be put into a cell as Greg proposes, not just the index variable. (In both for and while loops.) At the end of each loop iteration all such variables would need to be copied to the 'next' scope, which could be the parent scope or the next iteration. I'm trying really hard to think about cases that would break if this new behaviour was introduced, but I can't think about anything. The only thing that would 'break' is if you would want the standard example of lst = [] for i in range(10): lst.append(lambda: i) for f in lst: print f() to actually print 9 times 10. But if you want your bunch of lambda functions that you create in the loop body to all refer to the last value of i, why on earth would you even attempt to create a whole bunch of lambdas in this way?? (except to show that for loops are broken) Dillon Collins wrote:

...

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.

Are you suggesting doing something with the scope of all block constructs? If the variables of the block are copied into their outer scope at the end, there really is allmost no difference between, say, an if block with it's own scope and the if blocks we have now. The only time it matters is if the block is executed multiple times and if a variable is closed over in it. So that's only in loops that create functions/lambdas in their bodies. If you are suggesting to only introduce a new 'scope' keyword or something like that and leave loops alone, I'd say I would prefer to fix the loops without introducing new grammar. Greg wrote:

More generally, Python's inability to distinguish clearly between creating new bindings and changing existing bindings interacts badly with nested functions.

I agree that the wider problem needs to be addressed somehow, and perhaps that should be the starting point. Depending on the solution adopted, we can then look at whether a change to the for-loop is still needed.

The (IMO) natural approach that many functional-minded languages take is to have each block-like structure create a new scope. I think your proposal with cells for loop variables would fix it for loops, if it is applied to all variables closed over in a loop. But in other block structures that aren't executed repeatedly, this problem doesn't come up. Are there any other problem cases that aren't taken care of by this proposal or the 'nonlocal' keyword? Andrew Clover wrote:

You mean:

...

...

...

i= 0 geti= lambda: i

...

...

...

for i in [1]: ... print i is geti() True

...

...

...

for i in [1]: ... dummy= lambda: i ... print i is geti() False

This does point at an implementation gotcha. The global i and the i in the 'current' loop scope have to be kept in sync. But actually having two variables and keeping them synchronized so they appear to be one is near impossible due to pythons dynamic nature and multithreading. So this would require the variable i to be both a global variable and a cell variable. The module namespace dict would need to point to the cell containing i. This would require the python interpreter to check on every global lookup if it is looking at the value itself or at a cell containing the value. Perhaps this could be done with an extra tag bit on the value pointers in the module namespace dictionaries. So for some annotated code:

...

...

i = 0 # globals()['i'] = 0 geti = lambda: i # The lambda looks up its 'i' in the global namespace for i in [1]: # The global is put into a cell if it is not already: # globals()['i'] = cell(globals()['i']) # Each iteration updates the cell with the new value # from the iterator: # globals()['i'].cellvalue = next(_iterator) ... dummy = lambda: i ... i += 1 # globals()['i'].cellvalue += 1 ... print i, i == geti() ... # At the end of every loop iteration # the cell is replaced with a fresh cell: # globals()['i'] = cell( globals()['i'].cellvalue ) 2 True

Whether a global variable contains a value or a cell is something the interpreter needs to check at runtime, but I think it would not have to be very expensive.

On 06/10/2008, Arnaud Delobelle wrote:

How do you want this to behave?

lst = [] a = [0]

for i in range(10):

a[0] = i lst.append(lambda: a[0]) for f in lst: print(f())

How about this?

for a[0] in range(10): lst.append(lambda: a[0]) for f in lst: print(f())

In my previous post I argued not to distinguish between the loop index variable and other 'loop-scope' variables, so both pieces of code should show the same behaviour. In what that behaviour is, there are two possibilities: 1) Treat arbitrary location specifications like a[0] the same as normal local/global variables. That would imply that both examples print 0, 1, ... 9. It would also imply that lists and other arbitrary python data structures need to be able to hold cells (over which the python interpreter transparently indirects, so they would not be directly visible to python code). So at the end of the second loop, the python memory layout looks like this: +---+ a ---> |[0]| -----------\ +---+ | lst | | | v | +---+ v |[9]| ---> lambda ---> cell ---> 9 |[ ]| |[8]| ---> lambda ---> cell ---> 8 |[ ]| |[7]| ---> lambda ---> cell ---> 7 |[ ]| ... (Note in case ascii art breaks: a[0] is pointing to the cell that holds the 9, the same one lst[9]'s lambda is pointing at.) But I think this would be a better solution: 2) Treat location specifiers other than local and global variables (variables you can write down without using dots or square brackets) the same as they are treated today. In that case, both loops would print ten times 9. I would want to argue this is the better approach, because when you write down a[0] you are specifically thinking of a and a[0] in terms of objects, while when you use a local variable you just need some place to store a temporary result, and not be bothered with it any more than absolutely necessary. However, I don't think anyone in their right mind would write loops using a[0] as the index variable. Have you ever had the need to do this?

ATM, I think this proposal will only make things more complicated from every point of view.

Partly true, more (variants of) proposals makes decisions harder. But you should read my proposal as merely extending Gregs original proposal of using cells in loop indexes to all variables that are used in loops, obviating the need for a separate scope/let construct. So I think it has a place in this discussion. Jan

On 08/10/2008, Bruce Leban wrote:

I don't think this is better. Not that I'm proposing we add macros to the language but if we did then

macro find(a, x, i): for i in range(len(x)): if x[i]: return lambda: x[i]

would operate differently for find(a, x, i) and find(a, x, i[0]). I think that's a bad idea.

No, it wouldn't. The loop stops iterating as soon as one lambda is created, so the whole situation which started this thread, with multiple lambdas being created in a loop and each next iteration 'overwriting' the variable the previous lambdas refer to, does not occur. Your example would behave the same under current semantics, under my proposal, and under my proposal with complex variables also being 'celled' (the variant I don't prefer). Also, as you say, Python doesn't actually have macros and isn't going to get them any time soon. Saying that my proposal doesn't interact nicely with feature X which python doesn't have and is not going to get in the forseeable future is not really a convincing argument. You are more likely to convince me if you can show an actual example in which a[0] or an other non-simple variable is used as index variable. Like I said before, I don't think such a situation occurs, and if it does you'd want the behaviour I defended previously. Jan

Guido van Rossum wrote:

On Fri, Oct 3, 2008 at 3:37 AM, Greg Ewing wrote:

...

However, it's not lambda that's broken, it's the for loop.

I disagree. If you propose to change the for-loop to create new cells, you would also need to introduce new syntax for introducing new cells in other contexts. While it is common (especially when demonstrating the problem) to use a for loop variable in the lambda, the same problem exists when the variable referenced is constructed via other means.

Like this? >>> i = 0 >>> f = lambda: i >>> i = 1 >>> f() 1 Whether the for loop is broken really depends on what's meant by "broken". Some would say the very idea of cells is broken because *values* ought to be closed over. That's bunk, of course. ;) But I think most people are comfortable with the above example. If you unroll the loop, current behavior makes perfect sense: >>> f = [] >>> for i in [0, 1]: f.append(lambda: i) ... >>> [g() for g in f] [1, 1] >>> f = [] >>> i = 0 >>> f.append(lambda: i) >>> i = 1 >>> f.append(lambda: i) >>> [g() for g in f] [1, 1] But the deal with loops is that we don't usually unroll them in our heads when we reason about their behavior. We generally consider each iteration in isolation, or as an abstract single iteration. (After all, it only appears once in the program text.) If iterations need to depend on each other, it's almost always done via something that already exists outside the loop. The semantics that best matches that kind of reasoning is fully scoped loops. Python 4000 for scoped blocks? Neil

I don't think the for loop is broken. If you want scopes other than global and function, then you should add that explicitly, maybe something like: a = [] for i in range(10): local k: k = i**2 a.append(lambda: k) # k is not accessible here a[3]() => 9 which is roughly equivalent to: a = [] for i in range(10): def local_k(): k = i**2 a.append(lambda: k) local_k() --- Bruce

On Fri, Oct 3, 2008 at 10:56 PM, Greg Ewing wrote:

Guido van Rossum wrote:

This leads me to reject claims that "the for-loop is broken" and in

...

particular clamoring for fixing the for-loop without allowing us to fix this example.

Yeah, I never said the for-loop was the *only* thing that's broken. :-)

Perhaps "broken" is too strong a word. What I really mean is that it's designed in a way that interacts badly with nested functions.

More generally, Python's inability to distinguish clearly between creating new bindings and changing existing bindings interacts badly with nested functions.

I agree that the wider problem needs to be addressed somehow, and perhaps that should be the starting point. Depending on the solution adopted, we can then look at whether a change to the for-loop is still needed.

Since this idea didn't get much steam, a more modest proposal would be to relax the restriction on cells: allow the creation of new cells and the rebinding of func_closure in pure Python. Then one could explicitly create a new scope without any other change in the language through a 'localize' decorator that would create a new cell for every free variable (i.e. global or value from an enclosing scope) of the function: lst = [] for i in range(10): @localize def f(): print i lst.append(f) lst.append(localize(lambda: i**2)) I'd love to be proven wrong but I don't think localize() can be implemented in current Python. George

On Mon, Oct 13, 2008 at 8:09 AM, Arnaud Delobelle wrote:

Since this idea didn't get much steam, a more modest proposal would be to

...

relax the restriction on cells: allow the creation of new cells and the rebinding of func_closure in pure Python. Then one could explicitly create a new scope without any other change in the language through a 'localize' decorator that would create a new cell for every free variable (i.e. global or value from an enclosing scope) of the function:

lst = [] for i in range(10): @localize def f(): print i lst.append(f) lst.append(localize(lambda: i**2))

I'd love to be proven wrong but I don't think localize() can be implemented in current Python.

I think you probably can in CPython, but that would involve bytecode introspection and using ctypes.pythonapi.PyCell_New, and it would be terribly inefficient. I wrote a similar decorator that takes a function and bind some of its variables to some values. e.g

@bind(x=40, y=2) def foo(): return x+y

...

...

...

foo() 42

It's useless of course.

Can you expand a bit on that ? Why would it be terribly inefficient and why is it useless ? George

On Mon, Oct 13, 2008 at 2:05 PM, Arnaud Delobelle wrote:

On 13 Oct 2008, at 15:22, George Sakkis wrote:

On Mon, Oct 13, 2008 at 8:09 AM, Arnaud Delobelle

...

wrote:

...

Since this idea didn't get much steam, a more modest proposal would be to relax the restriction on cells: allow the creation of new cells and the rebinding of func_closure in pure Python. Then one could explicitly create a new scope without any other change in the language through a 'localize' decorator that would create a new cell for every free variable (i.e. global or value from an enclosing scope) of the function:

lst = [] for i in range(10): @localize def f(): print i lst.append(f) lst.append(localize(lambda: i**2))

I'd love to be proven wrong but I don't think localize() can be implemented in current Python.

I think you probably can in CPython, but that would involve bytecode introspection and using ctypes.pythonapi.PyCell_New, and it would be terribly inefficient. I wrote a similar decorator that takes a function and bind some of its variables to some values. e.g

@bind(x=40, y=2) def foo(): return x+y

...

...

...

foo() 42

It's useless of course.

Can you expand a bit on that ? Why would it be terribly inefficient and why is it useless ?

When I was saying it was useless, I was talking about my bind decorator of course!

It's useless because the above can be written

def foo(x=40, y=2): return x+y

But the whole point of this thread is that this is an abuse of default arguments since it changes f's signature; f(5,6), f(1), f(y=10) should all raise TypeError. It's inefficient because it works by deconstructing and reconstructing the

function bytecode.

But this happens only once at decoration time, not every time f is called, right ? George

On 14 Oct 2008, at 05:03, Dillon Collins wrote:

On Monday 13 October 2008, Arnaud Delobelle wrote:

...

It's inefficient because it works by deconstructing and reconstructing the function bytecode.

That's not necessary. Just make a new closure for it. Here's some code (I was bored/curious). The function reclose_kwds is provided for fun. Enjoy:

But that doesn't work with global variables, does it? Globals are the reason why I had to scan the bytecode -- Arnaud

2008/10/14 Dillon Collins :

On Tuesday 14 October 2008, Arnaud Delobelle wrote:

...

On 14 Oct 2008, at 05:03, Dillon Collins wrote:

...

On Monday 13 October 2008, Arnaud Delobelle wrote:

...

It's inefficient because it works by deconstructing and reconstructing the function bytecode.

That's not necessary. Just make a new closure for it. Here's some code (I was bored/curious). The function reclose_kwds is provided for fun. Enjoy:

But that doesn't work with global variables, does it? Globals are the reason why I had to scan the bytecode

Nope. However, I expect that globals would be even easier. If you want to freeze all the variables, you can just replace func_globals with func_globals.copy(). Otherwise, you can replace it with some proxy object that would read from your dict and fall back to the real globals if necessary. (Probably subclass dict with the __missing__ method.)

I guess you're right. My version was just an adaptation of the 'bind' decorator that I mentioned above, where only *some* non local variables were 'frozen', so I had to change the bytecode for that. I tried just to adapt it but it was the wrong approach! Anyway here is another version, without using bytecode introspection or ctypes: def new_closure(vals): args = ','.join('x%i' % i for i in range(len(vals))) f = eval("lambda %s:lambda:(%s)" % (args, args)) return f(*vals).func_closure def localize(f): f_globals = dict((n, f.func_globals[n]) for n in f.func_code.co_names) f_closure = ( f.func_closure and new_closure([c.cell_contents for c in f.func_closure]) ) return type(f)(f.func_code, f_globals, f.func_name, f.func_defaults, f_closure) -- Arnaud

Dillon Collins wrote:

And, unless I'm mistaken, this would make for loops incompatible with comprehensions:

No, the same thing would be done in list comprehensions as well (except for preserving the final value, since LC variables no longer leak). -- Greg

Greg Ewing wrote:

Terry Reedy wrote:

...

Here are 5 more alternatives that have the same effect:

All of which are even worse, to my eyes.

If you mean worse than the simple default arg hack, I could be persuaded. But the default arg issue is a red herring. There is no need for what you call abuse, as I amply demonstrated, and there is no way for you to stop others from (mis)using them without removing them. If you mean worse than turning for-loops into an esoteric CS monster (my view), we disagree. My deeper objection is this. Your intended-to-be-motivating example, similar to what others have occasionally posted, is a toy snippet that illustrates some points of Python behavior, but which I see no use for in real application code. Given def f(i): return i; your lst[i]() is equivalent to f(i). So just write and use the function. OK, to be persnickety, we need more code, of about the same length as needed to generate lst: def f(i): if not isinstance(i,int): raise TypeError("requires int i") if not -10 <=i <10: raise ValueError("requires -10 <= i < 10") return i So, as near as I can see, your list of identical functions with variant closure cells simulates type and range checking. What is the point of that? Perhaps you have an undisclosed real use case with much more complicated closures. It would still be true that the array index could instead to fed to the function as an arg. If there were really a reason not to do that, the 15 keystroke overhead would be relatively much smaller for more complicated (and realistic) closures. Terry Jan Reedy

On 4 Oct 2008, at 05:12, Greg Ewing wrote:

Terry Reedy wrote:

...

Your intended-to-be-motivating example ... is a toy snippet that illustrates some points of Python behavior, but which I see no use for in real application code.

My example wasn't intended to prove the existence of the problem, only refer to an already-acknowledged one. Its existence is attested by the fact that people regularly get tripped up by it.

Here's a more realistic example:

menu_items = [ ("New Game", 'new'), ("Resume", 'resume'), ("Quit", 'quit') ]

buttons = [] for title, action in menu_items: buttons.append(Button(title, lambda: getattr(game, action)()))

Isn't this better as: buttons.append(Button(title, getattr(game, action))) Unless you want late binding of 'game', but that would be confusing.

which gives you three buttons that all execute the 'quit' action.

-- Arnaud

Greg Ewing wrote:

Arnaud Delobelle wrote:

...

Isn't this better as:

buttons.append(Button(title, getattr(game, action)))

Unless you want late binding of 'game',

Well, you might, for example if you implement restoring a saved game by unpickling a Game object and assigning it to game.

To me, this example and comment proves my point. If you want 'action' interpolated immediately, to not actually be a variable of each function, while you want 'game' left to be a true free variable, then overtly say so specifically in one way or another without magic. In my opinion, the 'evil default arg hack' does this nicely (though not completely), especially if a new name is used for the lambda local. lambda a=action: getattr(game,a) This is only 4 extra keystrokes. If the function is left anonymous and only called by clicking a button, there is no danger of a 'user' accidentally calling the function with an extra arg that overrides the default. This fact to me eliminates the main objection to the usage. If one still does not like that for whatever reason, complete value interpolation is nicely done by eval("lambda: getattr(game,%s)" % action) That is 13 extra spaces, including 2 spaces for easier reading.

There's always some way to rearrange it so that it works,

Also my point.

but the point is that it's easy to write things like this that don't work, unless you really keep your wits about you.

It is also easy to write things that don't work, unless you really keep your wits about you, with lists and other mutables, and with floats ;-). Terry Jan Reedy