[issue42185] class body bytecode uses less efficient *_NAME opcodes

Serhiy Storchaka added the comment: It cannot use LOAD_GLOBAL because the name can be not global. For example: def f(self): ... f = property(f) It cannot use STORE_FAST and LOAD_FAST because they work with specific representation of locals as array, but in a class body it can be

[issue42185] class body bytecode uses less efficient *_NAME opcodes

Brandt Bucher added the comment: In any case, I think the proposed change could break the current behavior: >>> x = "global" >>> class C: ... x = "local" ... l = x ... del x ... g = x ... >>> C.l 'local' >>> C.g 'global' -- ___

[issue42185] class body bytecode uses less efficient *_NAME opcodes

Brandt Bucher added the comment: Actually, that doesn't make much sense in this context (more relevant would be a class-within-a-class or class-within-a-function). I need to think about this more... -- ___ Python tracker

[issue42185] class body bytecode uses less efficient *_NAME opcodes

Brandt Bucher added the comment: Hm, I believe it is related to the reason why we need to use LOAD_CLASSDEREF instead of LOAD_DEREF with nonlocal names in class scope. If I understand correctly, the purpose is to keep nonlocal statements in methods from referencing class-level names. >From

[issue42185] class body bytecode uses less efficient *_NAME opcodes

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42185] class body bytecode uses less efficient *_NAME opcodes

New submission from Gregory P. Smith : The opcodes generated for the closure defining a class body looks like they might be suboptimal. It seems stuck using the generic LOAD_NAME and STORE_NAME opcodes rather than the LOAD_GLOBAL and STORE_FAST and friends as one would expect and as happens