Consider sequences of bytecode operations on fast locals like the following:
>>> def f(x): # declare as parameter so that x is a fast local ... x ... >>> dis(f) 2 0 LOAD_FAST 0 (x) 2 POP_TOP 4 LOAD_CONST 0 (None) 6 RETURN_VALUE Given the following assumptions: - a LOAD_FAST cannot possibly have any side-effects outside the interpreter stack [1] - a POP_TOP immediately undoes LOAD_FAST's effects on the interpreter stack I am wondering: why doesn't the peephole optimiser remove these opcode constructs? Is it maybe because of PEP 626 - an introspection tool needs to know that the variable is being used there? Although surely in that case the peephole optimiser could just replace it with a single NOP? (c.f.: https://bugs.python.org/issue42719) Or is one of my assumptions wrong? [1]: global variables are probably supposed to have the same guarantee, but in practice this is not the case, which is why I'm focusing on the _FAST ones; see for example https://ato.pxeger.com/run?1=m72soLIkIz9vwYKlpSVpuhY3JyXnJBYXK_hWumQml2ikAAlNKy4FIEhJTVOIj09PLcksSc2Nj9coTs1J01HITq2EyoNAQVFmXomGUnFmSqpCalpaanKJoqKSJly6KLWktChPobi0ILVIQ1MP2TSQOVxcqRWpyRpKFUo6MPsrbA01NSEugzoQ5lAA _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/767FGRV4ZL5IVBHWSAW5TJGQMGQS244Z/ Code of Conduct: http://python.org/psf/codeofconduct/
