Logged In: YES 
user_id=432579

>The source of the problem is that scoping decisions are made
>statically.

No, because other languages with lexical scope and
permitting evaluation at runtime have no problem whatsoever
with this. They just answer the question:

Q: In what environment is the eval() argument evaluated?

typically in one of three ways:

A1. In an empty environment with no bindings at all, or just
the language-defined standard bindings.
A2. In the (or a) top-level environment; local, lexically
bound variables where the eval() takes place are not visible
to the argument expression.
A3. In the same lexical environment as the eval() call itself.

Perl and Ruby both say A3. Scheme (R5RS) lets the user
specify A1 or A2. Common Lisp answers A2.

Observe that none of the answers depend on what the
expression looks like.

Now, let's be crystal clear about this: The rules of where x
is looked up in the expressions

1) x

and

2) lambda: x

should reasonably be the same - after all, this is
fundamentally how lexical scoping works. And Python does
indeed work this way, to everybody's satisfaction.

In case 2), the evaluation of x is delayed, but that is
irrelevant; the decision of what x means is taken at the
same time in both cases, and the decision will be the same.

Most people would expect Python to answer question Q above
with one of the answers A1-3, but it does not, and it does
not document what the answer is. The Python answer is rather:

A4. A mixed hybrid environment of some kind: The identifiers
representing variables that are to be evaluated immediately
are looked up in the lexical environment of the eval
expression; identifiers representing variables in
delayed-evaluation positions use the global environment.

This answer is not very satisfactory and I'm inclined to
consider a design bug; it is different from what everyone
else does and not very intuitive. However, I can accept that
it is hard to change now for compatibility reasons. But this
answer A4 should be documented.