[Python-Dev] LOAD_NAME & classes

[Jeremy Hylton]

>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

  >> I think you misunderstood my original explanation.  With the
  >> current implementations, the first example fails and the second
  >> example works.  I think the bug is that the second example works.

  GvR> But it has always worked, and I definitely don't want to break
  GvR> this now.

I don't want to break this now either (although I don't think either
of my messages betrayed that intent).  I think it's a wart we live
with, but I'd love to fix it when we get to Py3K.  (Will we ever?)

  GvR> I don't understand why you want to break it?  That would
  GvR> definitely break working code!

And there's the rub.

  >> I think the problem is with x = x, which ought to be an error if
  >> x is a local and x is unbound.  The code will succeed, nested or
  >> otherwise, if x happens to be a module global.  The confusion is
  >> that the code will not succeed if x is defined in an enclosing,
  >> non-top-level scope.

  GvR> Nested scopes in Python will never be completely intuitive,
  GvR> because they break the illusion that "there's only runtime" (as
  GvR> Samuele summarized it a while ago).

Wasn't that about macros?

  GvR> That said, I can't decide whether it's better to make the first
  GvR> example work, or reject the bug report.  I'm tempted to say
  GvR> "the ice is thin here, don't play with fire" or something
  GvR> cryptic like that, and leave it.

In the bug tracker (532860), I suggested "The result of a reference to
an unbound local name in a class block is undefined."  With a note
that says this is for backwards compatibility and another that
explains how CPython is currently implemented.

I have a separate bug report about ref man documentation for all
this.  The ref man documents that world the way I'd like it to be,
nicely glossing over all the messy details like LOAD_NAME.  I think we
need an extra section (4.1.1) that explains some of the messy details.

Jeremy