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

Guido van Rossum guido at python.org
Tue Sep 27 06:12:07 CEST 2011


On Mon, Sep 26, 2011 at 8:53 PM, Spectral One <ghostwriter402 at gmail.com> wrote:
> On 9/26/2011 9:48 PM, Guido van Rossum wrote:
>>
>> On Mon, Sep 26, 2011 at 7:43 PM, Nick Coghlan<ncoghlan at gmail.com>  wrote:
>>>
>>> Despite what I wrote earlier in the thread, I don't think we actually
>>> need to declare the idea *dead* if you don't currently like 'nonlocal'
>>> as the keyword. Perhaps the 'nonlocal' idea will grow on you (it
>>> certainly did on me, the longer I considered the idea), or perhaps you
>>> or someone else will come up with an appropriate keyword that everyone
>>> considers reasonable.
>>
>> Sorry, from reading the responses, the objection that the other use of
>> nonlocal refers to scope, not lifetime, seems pretty common, and I
>> don't think it will go away. You might as well use "def var = expr" as
>> the syntax and justify it by saying that it is clearly defining
>> something and syntactically different from function definitions...
>>
>> OTOH I am happy to let you all bikeshed on a better name.
>
> I was actually considering asking whether using 'def.static' or
> 'def.initial' would be a possible way to avoid making a new keyword. I
> honestly prefer def to nonlocal for this. I like that "our" is short, but
> while it's less confusing, I don't see is as clear.

"our" is something in Perl, right? My proposal was "own", which is
much older (Algol-60). Probably nobody else here remembers it.

> Questions on options:
>   Could there be an importable "function" that, when used, declares a
> variable to be one of these?

The compiler would have to recognize that function as special, which
is not really possible, since the Python compiler has no access to the
runtime environment, so it can't know what is imported (__future__ is
the exception, and that's why it's a __xxx__ word).

>   Could the keyword be toggled in or out of namespaces based on, say, an
> imported module? If so, the keyword wouldn't be terribly burdensome.

We do that regularly with "from __future__ import
<some_syntactic_feature>" and when the parser sees it, it modifies
itself (slightly). Modifying the list of reserved words is easy. But
it's not a long-term solution.

Somehow you triggered a thought in my head: maybe se should stop
focusing on the syntax for a while and focus on the code we want to be
generated for it. If we can design the bytecode, perhaps that would
help us come up with the right keyword.

> The following could also add to Nick's list of keyword options:
>  init (or Initial or even initialize) retain hold held persist preserve keep
> kept lasting stash survive ark reshiyth
>
> Given the frequency of the use case, clarity probably trumps concerns about
> keyword length.
> To my eye, those all seem more congruous than "nonlocal."
>
> (Nick's list:
> nonlocal once static persistent shared closure own atdef deftime)

-- 
--Guido van Rossum (python.org/~guido)



More information about the Python-ideas mailing list