On 7/12/20 9:04 AM, Daniel Moisset wrote:
The existing implementation has optimizations here. If that's
important, we could achieve the same result with a little dataflow
analysis to optimize away the dead store. We could even
special-case optimizing away dead stores /only/ to '_' and /only/
in match/case statements and all would be forgiven.
This might work, although it's quite different to what python does in
general (are you supposed to see the value of `_` in a debugger? or in
`locals()`? )
All excellent points. The debugger question is easier to answer.
Debuggers for compiled code have dealt with this for years; I'm unsure
of the exact wording but gdb prints something like "<value optimized out>".
As for locals(), my first thought was "suppress the optimization in the
presence of a locals() call". I dimly recall a precedent where the
presence of locals() in a function body affected code generation, though
sadly it escapes me at the moment**. Anyway, that seems like a nasty
hack, and it only handles one method of extracting a locals
dict--there's several more, including sys._getframe and
inspect.getframeinfo. And then the user could rebind those and we
wouldn't notice. This seems like a non-starter.
Having thought about it some, I propose it'd be acceptable to do dead
store optimization if-and-only-if optimizations are explicitly enabled,
e.g. with "-O". Allowing explicitly-enabled optimizations to observably
affect runtime behavior does have some precedent, e.g. "-OO" which
breaks doctest, docopt, etc. It'd be a shame if the existence of
locals() et al meant Python could never ever perform dead store
optimization.
Your other (elided) point is correct too, about sequence matching for a
sequence we don't care about not being as cheap and simple as a store
and an extra reference.
Cheers,
//arry/
** Or maybe I'm confused and thinking of something else entirely. Maybe
it was "import * inside a function body disables fast locals in Python
2"? But that doesn't seem to be true either.
_______________________________________________
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/G3DZWKV4MAGWHF3B3VI3RLGVPW3ALCRT/
Code of Conduct: http://python.org/psf/codeofconduct/
