[Python-ideas] Allow lambda decorators

[Ron Adam]

Correction/Note:  Both examples I gave use globals and not closures, but I 
still hold my preference against them because it's still too easy to make 
subtle mistakes with them.  One of which is to use a global where a closure 
is intended. ;-)

    Ron




Ron Adam wrote:
> 
> 
> 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