[Python-Dev] LOAD_NAME & classes (original) (raw)

Guido van Rossum guido@python.org
Mon, 22 Apr 2002 15:04:32 -0400

>>>>> "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).

The fact that you called it a bug (rather than a problem) made me think this.

I think it's a wart we live with, but I'd love to fix it when we get to Py3K. (Will we ever?)

There probably won't ever be an opportunity to start over and be truly incompatible. I don't think I'm up for a herculean effort like the Perl 6 folks are making.

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?

That was the context, but it nicely summarizes a lot about Python, and about scripting languages in general. It may even be an explanation of the success of scripting languages: typical programmers probably have a much better mental model of runtime than of compile time.

Variable scope already violates the "only runtime" rule, and this has caused endless complaints and misunderstandings. Before nested scopes, I've toyed with the idea of making LOAD_FAST fall through (conceptually) to LOAD_GLOBAL when the local slot is NULL, just to shut up the complaints. Then this example (whose failure always surprises newcomers) would work:

x = 10
def f():
    print x
    x = 12
f()

But now that we have nested scopes, I don't think this would be feasible -- the fallback would have to dynamically inspect all surrounding scopes.

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.

At least this leaves the door open to fixing it my way. :-)

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 LOADNAME. I think we need an extra section (4.1.1) that explains some of the messy details.

You can never go wrong by documenting something. (Famous last words, I expect. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)