The problem with statement local variables is that the extent over
which the name is in scope is not as clear to the human reader (the
rules the *compiler* follows may be precise, but they aren't obvious
to the human reader - that's the root of the debate I'm having with
Chris over "what the reference implementation does isn't a sufficient
spec"). In particular, assignment statements are non-obvious, as shown
by the examples that triggered your suggestion of a "." prefix.
> Adding statement local variables into that mix *without* some form of
> syntactic marker would mean taking an already complicated system, and making
> it even harder to reason about correctly (especially if statement locals
> interact with nested scopes differently from the way other locals in the
> same scope do).
Well, an alternative to a syntactic marker would be an
easy-to-determine extent. That's where proposals like PEP 3150 (the
"given" clause) work better, because they provide a clearer indication
of the extent of the new scope. IMO, lack of a well-defined extent is
a flaw of this proposal, and syntactic markers are essentially a
(ugly) workaround for that flaw.
> Thus the intent behind the ".NAME" suggestion is to ask whether or not it's
> possible to allow for name bindings that are strictly local to a compilation
> unit (i.e. without allowing dynamic runtime access to outer scopes or from
> contained scopes), *without* incurring the cost of making ordinary NAME
> references even more complicated to understand.
... or the cost of imposing a more user-visible indication of the
extent of the scope into the proposal.