[Python-Dev] Unbound locals in class scopes

[Nick Coghlan]

On 22 June 2015 at 08:46, Ivan Levkivskyi <levkivskyi at gmail.com> wrote:
>
>
> On 21 June 2015 at 22:05, Guido van Rossum <guido at python.org> wrote:
>>
>> On Sun, Jun 21, 2015 at 6:22 PM, Ivan Levkivskyi <levkivskyi at gmail.com>
>> wrote:
>>>
>>> It is still not clear whether Guido's comment still stands for not
>>> raising an UnboundLocalError in class definitions but using globals instead.
>>
>>
>> Can you phrase this in the form of an example, showing what it currently
>> does and what you think it should do, instead?
>>
>
> Here is an example:
>
> x = "xtop"
> y = "ytop"
> def func():
>     x = "xlocal"
>     y = "ylocal"
>     class C:
>         print(x)
>         print(y)
>         y = 1
> func()
>
> prints
>
> xlocal
> ytop
>
> Intuitively, one might think that it should raise UnboundLocalError or print
> ylocal instead of ytop.
> This question was discussed 13 years ago and then you said that this lookup
> in globals
> is an intentional behavior.
>
> This behavior is not documented, and I started an issue on bug tracker
> about documenting it.
> Then, Eric proposed to ask you again, whether this is still an intentional
> behavior.

Diving into some bytecode details:

We added LOAD_CLASSDEREF
(https://docs.python.org/3/library/dis.html#opcode-LOAD_CLASSDEREF) a
while back to account for the fact that __prepare__ may inject locals
into a class body that the compiler doesn't know about. Unlike
LOAD_DEREF, LOAD_CLASSDEREF checks the locals before it checks the
closure cell.

However, neither LOAD_CLASSDEREF *nor* LOAD_DEREF is used for names
that are *assigned* in the class body - those get flagged as local
variables, so we end up emitting LOAD_NAME for them, and hence ignore
any nonlocal variables with that name. If a module global or builtin
exists, we'll find that, otherwise we'll throw NameError.

With nested_scopes having been the default since 2.2, and accounting
for the fact that folks *do* write code like "name = name" at class
scope and expect it to "do the right thing", it seems reasonable to me
to just make this work properly, rather than having to explain why it
doesn't work as one might expected based on the behaviour of module
level class definitions and other references to nonlocal variables
from a class body.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia