[Python-ideas] Allow lambda decorators

[Ron Adam]

Aahz wrote:
> On Mon, Feb 09, 2009, Guido van Rossum wrote:
>> In regard to the proposal of "bind i" syntax, I have a
>> counter-proposal (as log as we're in free association mode :-):
>>
>> Define new 'for' syntax so that you can write
>>
>>   [lambda: i for new i in range(10)]
>>
>> or e.g.
>>
>>   fs = []
>>   for new i in range(10):
>>     def f():
>>       return i
>>     fs.append(f)
>>
>> The rule would be that "for new <name> in ..." defines a new "cell"
>> each time around the loop, whose scope is limited to the for loop. So
>> e.g. this wouldn't work:
>>
>>   for new i in range(10):
>>     if i%7 == 6:
>>       break
>>   print i    # NameError
>>
>> I'm not saying I like this all that much, but it seems a more Pythonic
>> solution than "bind i", and it moves the special syntax closer to the
>> source of the problem.
> 
> Nice!  This does seem like it would work to quell the complaints about
> for loop scoping while still maintaining current semantics for those who
> rely on them.  Anyone wanna write a PEP for this?...
> 
> Anyone who does tackle this should make sure the PEP addresses this:
> 
>     for new x, y in foo:
> 
> versus
> 
>     for new x, new y in foo:
> 
> (I'll channel Guido and say that the second form will be rejected; we
> don't want to allow multiple loop targets to have different scope.  IOW,
> ``for new`` becomes its own construct, functionally speaking.)

Personally, I think when ever a state or data is to be stored, objects 
should be used instead of trying to get functions to do what objects 
already do.


Here's something that looks like it works, but...

 >>> f = {}
 >>> for i in range(10): f[i] = lambda:i
...

 >>> for i in f: f[i]()
...
0
1
2
3
4
5
6
7
8
9

It was only worked because I reused i as a variable name.


 >>> for j in f: f[j]()
...
9
9
9
9
9
9
9
9
9
9

I've always thought closures cause more problems than they solve, but I 
doubt closures can be removed because of both how many programs are already 
written that use them, and because of the number of programmers who like them.

One of the reasons I dislike closures is a function that uses a closure 
looks exactly like a function that uses a global value and as you see above 
is susceptible to side effects depending on how and when they are used.

Guido's 'new' syntax would help, but I'm undecided on weather it's a good 
feature or not.

I'd prefer to have an optional feature to turn on closures myself.  Maybe 
an "__allow_closures__ = True" at the beginning of a program?

Shrug,
   Ron