On 10/10/2021 18:26, Brandt Bucher wrote: > 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. Ah, ok, that certainly explains it - thanks! _______________________________________________ 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/GLQ4LXLZZMRLDQQJTDM2CZOFNJ62I6JE/ Code of Conduct: http://python.org/psf/codeofconduct/
- [Python-Dev] Why doesn't peephole optimise away operation... Patrick Reader
- [Python-Dev] Re: Why doesn't peephole optimise away ... Guido van Rossum
- [Python-Dev] Re: Why doesn't peephole optimise away ... Brandt Bucher
- [Python-Dev] Re: Why doesn't peephole optimise a... Guido van Rossum
- [Python-Dev] Re: Why doesn't peephole optimi... Patrick Reader
- [Python-Dev] Re: Why doesn't peephole op... Guido van Rossum
- [Python-Dev] Re: Why doesn't peepho... Brandt Bucher
- [Python-Dev] Re: Why doesn't pe... Dennis Sweeney
- [Python-Dev] Re: Why doesn'... Guido van Rossum
- [Python-Dev] Re: Why doesn't peepho... Serhiy Storchaka
- [Python-Dev] Re: Why doesn't peephole optimise a... Patrick Reader
- [Python-Dev] Re: Why doesn't peephole optimise away ... Steven D'Aprano