I can think of two reasons.
The first reason is that this operation *does* have a side-effect: if a fast
local is unbound, the load will raise a NameError!
def f():
x # This should always raise.
x = None # This makes x a fast local.
The second reason is one that Guido already alluded to: the peephole optimizer
shouldn’t be tasked with “fixing” poorly-written or uncommon code… just
improving common code.
If anything, we would probably just warn here. But even that seems like too
much.
Brandt
_______________________________________________
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/TJKKOVORTSM5QVRV5WXMUUKBUDYN2IQ7/
Code of Conduct: http://python.org/psf/codeofconduct/
