09.04.20 00:54, Andrew Barnert via Python-ideas пише:
Could you go so far as to remove the variable from the locals if its only assignment(s) are optimized out? I’m not sure how much benefit that would provide. (Surely it would sometimes mean an f_locals array fits into one cache line instead of two, or that a whole code object stays around in L2 cache for the next time it’s called instead of being ejected, but often enough to make a difference? Maybe not…)
I did no do this specially, it was a natural consequence of optimizing out assignments. So yes, they are removed from f_locals.
Like Guido’s idea, this seems like something that should definitely be safe enough as an opt-in decorator or whatever, and implementable that way. And that also seems like the best way to answer those doubts. Write or find some code that you think should benefit, add the decorator, benchmark, and see.
Also, with an opt-in mechanism, you could relax the restrictions. For example, by default @killunused only kills unused assignments that meet your restrictions, but if I know it’s safe I can @killunused("_”, “dummy”) and it kills unused assignments to those names even if it wouldn’t normally do so. Then you could see if there are any cases where it’s useful, but only with the restrictions relaxed, and maybe use that as a guide to whether it’s worth finding a way to aim for looser restrictions in the first place or not.
It would be much more complex. It is just 30 lines of simple code added in symtable.c and compile.c, but with the decorator you would need to write complex code in Python which parses bytecode, analyzes dataflow, patches bytecode, removes names from locals and recalculates all local's indices. I am not interesting in doing this.