Is it me or a python wart

[John Roth]

"Just van Rossum" <just at xs4all.nl> wrote in message
news:just-9E8624.12281026042002 at news1.xs4all.nl...
> In article <C2cBaXANXSy8Ewbb at jessikat.demon.co.uk>,
>  Robin Becker <robin at jessikat.fsnet.co.uk> wrote:
>
> > With 2.2.1 I'm puzzled why the first returns the local x and the
second
> > the global I suppose x=x rather than z=x is the problem, but don't
> > understand why. I opposed local scopes originally as I liked the two
> > scope rule, but this seems more complex than I imagined.
> >
> > >>> x=2
> > >>> def bingo(x):
> > ...     class A:
> > ...             z=x
> > ...             def get(self):
> > ...                     return self.z
> > ...     return A().get()
> > ...
> > >>> bingo(4)
> > 4
> > >>> def bango(x):
> > ...     class A:
> > ...             x=x
> > ...             def get(self):
> > ...                     return self.x
> > ...     return A().get()
> > ...
> > >>> bango(4)
> > 2
>
> What a coincidence:
>    http://www.python.org/sf/532860
>    http://mail.python.org/pipermail/python-dev/2002-April/023427.html
>
> Just

This doesn't appear to be the same bug. Robin's example
has two functions which are identical, other than the
substitution of 'x' for 'z' in the definition of class A.

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.

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.

Of course, I could be totally confused, as usual.

John Roth