[Python-Dev] LOAD_NAME & classes

[Guido van Rossum]

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