Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)

[Evan Simpson]

Talin wrote:
> I propose to create a new type of scoping rule, which I will call 
> "explicit" lexical scoping, that will co-exist with the current 
> "implicit" scoping rule that exists in Python today.

I'd like to toss one more variant into the mix.  If we really need to
address variables in an intermediate scope, the most explicit way that I
can think of doing so is to write (using Philip's example):

def counter(num):
scope as outer # "outer" is an arbitrary identifier
def inc():
outer.num += 1
return outer.num
return inc

This is somewhat similar to the unworkable "use the function name"
method that's been suggested.  The "scope as X" statement associates the
name "X" with the namespace of local variables in the scope in which it
is executed.  Such names are "lexically scoped", and only allow access
to or rebinding of existing names from the originating scope (i.e. no
"del outer.num" allowed).

Cheers,

Evan @ 4-am

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)

[Evan Simpson]

Kevin Jacobs <[EMAIL PROTECTED]> wrote:
> Why not extend the interface to the locals builtin and add a __getitem__
> that returns a proxy to access locals defined in other lexical scopes
> via __{get/set/del}attr_:
> 
> def counter(num):
> num = 1
> def inc():
> locals[1].num += 1
> return outer.num
> return inc
> 
> Where, for CPython, locals[n] gives access to
> NamespaceProxy(sys._getframe(n).f_locals).

Two nits:  First, I suspect that you meant to write "return
locals[1].num".  Second, sys._getframe doesn't do what you want, here.
It reaches back up the call chain, not out into lexically containing scopes.

That said, I like the idea of giving "locals[]" the meaning you
intended.  It has the advantage of not adding any new keywords or
syntactic constructs, but the disadvantage of not explicitly signaling
that locals in a given scope will be twiddled elsewhere.  Also, for
efficiency's sake, it might be desirable to only allow a literal integer
as the index, and to deal with use of "locals[]" at compile time rather
than dynamically.  I'm not sure how much overhead would be involved in
enabling dynamic lookup of arbitrary lexically containing scopes, but I
would *not* want to enable stuff like "locals[i * 2 - 1]".

Cheers,

Evan @ 4-am

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com