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 -- [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/TJKKOVORTSM5QVRV5WXMUUKBUDYN2IQ7/ Code of Conduct: http://python.org/psf/codeofconduct/