Is it me or a python wart

[Jeremy Hylton]

"John Roth" <johnroth at ameritech.net> wrote in message news:<ucjicvlrf7djd3 at news.supernews.com>...
> The discussion in the bug report indicates that the 'x'
> following the '=' should be compiled using the 'LOAD_NAME'
> op code, which implements the old rules. If it in fact did this,
> I would expect the first example to return 4, not 2,
> because 'LOAD_NAME' is supposed to ignore the
> parameter.

(I hope this answer is clear without quoting the original code
example.)

LOAD_NAME is an old-fashioned beast that looks in the current
namespace, the global namespace, and the builtin namespace.  It never
raises an exception unless the name can't be found in any of those
namespaces. Note in particular that it's always three namespaces; in
the case of a nested block, enclosing namespaces are not searched.

Since LOAD_NAME is used for class namespaces, you'll never see an
unbound local error.  If a variable 'x' is a local but has not been
bound yet, LOAD_NAME will next search the globals and builtins.  If
the local happens to shadow a global or builtin, you'll get its value.
 Otherwise, you'll get a NameError.
 
> Clearly, it isn't. At a guess, I'd think the problem is that
> the compiler is trying to make 'z' a local variable of the
> def, so it's using a different op code in the first case than
> in the second.

No.  The compiler never "tries to make" a local variable bound in one
block into a local variable in a different block.

This stuff isn't documented, so it's no surprise that it's confusing. 
But I think the documentation will mostly be of the form:  The results
of XXX are undefined.  (The CPython implements currently does this
...)

Jeremy