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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/767FGRV4ZL5IVBHWSAW5TJGQMGQS244Z/
Code of Conduct: http://python.org/psf/codeofconduct/