[Python-ideas] Tweaking closures and lexical scoping to include the function being defined

Eric Snow ericsnowcurrently at gmail.com
Fri Sep 30 19:39:10 CEST 2011

On Fri, Sep 30, 2011 at 10:45 AM, Jan Kaliszewski <zuo at chopin.edu.pl> wrote:
> Ron Adam dixit (2011-09-30, 00:25):
>> How about anonymous wrappers?
>>   @@(x=0)
>>   def adder(y):
>>       nonlocal x
>>       x += y
>>       return x
>> which would be the same as...
>>   def _(x=0):
>>       def adder(y):
>>           nonlocal x
>>           x += y
>>           return x
>>       return adder
>>   adder = _()
> +1, though I'd rather prefer simply:
>    @(x=0)
>    def adder(y):
>        nonlocal x
>        x += y
>        return x
> And, of course, if you don't need to rebind the variable, `nonlocal`
> would not be needed:
>    @(lock=threading.RLock())
>    def my_foo():
>        with lock:
>            "do foo"
> IMHO it is better than @nonlocal because it uses already settled
> @-decorator idiom and at the same time it does not pretend to be a
> normal fuction-based decorator.
> I like it. :) I think it would be not only clear and useful but also
> beautiful.

On its own it actually looks very appealing.  And it may still be
fine.  However, when mixed with decorators, it may be too ambiguous:

   def my_foo():
       with lock:
           "do foo"


   def my_foo():
       with lock:
           "do foo"

What does "@(lock=threading.RLock())" do here?  It would be easy to
miss that it affects "my_foo" (at compile-time) and not the result of
"@does_something_else" (at def-time).  This is the problem with mixing
the syntax for a compile-time directive with that of a def-time
directive, particularly when they can show up right next to each

This is a possible solution: a syntax requirement that no real
decorators come after this new syntax.  I'm still cautious about the
idea of sharing syntax between compile-time and def-time directives.
However, default arguments sort of do this already.


> Cheers.
> *j
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas

More information about the Python-ideas mailing list