[Python-ideas] Tweaking closures and lexical scoping to include the function being defined
ncoghlan at gmail.com
Mon Sep 26 16:08:56 CEST 2011
On Mon, Sep 26, 2011 at 9:54 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Mon, Sep 26, 2011 at 8:26 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>> You had me, you really did. Right up until you showed the current equivalent.
>> This strikes me as a few things.
>> Most importantly, as you noted yourself, a pretty rare case, even in C static
>> variables are probably the rarest scope of variable. This strikes me as a) not
>> saving very much code, it's like crappy HFS instead of real sugar ;), and b)
>> not adding fundamental value, I think both blocks of code are equally readable.
>> Other examples of syntatic sugar, such as decorators, have code motion
>> properties that let you think about code in the places that makes sense, and I
>> don't think this has that.
> To my mind, a 4:1 reduction in boilerplate lines, moving the function
> name out to the top level, making it clear that there's only one
> function (the inner one) that is kept around, avoiding repetition of
> the variable name and the function name all count as fairly
> substantial wins on the 'sugary goodness' front :)
Oops, forget to mention that the toy examples I've been using for the
sake of brevity fail to convey one of the benefits of the syntax (i.e.
the elimination of all trailing boilerplate following the function
definition), since the body of the inner function is so short.
To be fair, a more accurate comparison would be to a '@closure'
decorator along the lines of something I posted in the previous
# Not clear if this is actually the right thing to do
# It depends on how you decide to handle annotations
# and whether decorators are applied to the inner or the
# outer function
"""Real function is the inner one"""
VAR = EXPR
def _inner(real, params, here): # Hidden signature!
nonlocal VAR # Still have to repeat VAR
# Arbitrarily long complex code here
return _inner # Still have this trailing boilerplate
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas