On 22 June 2015 at 08:46, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > > > On 21 June 2015 at 22:05, Guido van Rossum <gu...@python.org> wrote: >> >> On Sun, Jun 21, 2015 at 6:22 PM, Ivan Levkivskyi <levkivs...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
