What about nested functions? I am not sure how we can predict if that variable is going to be used or not.
I think this is a nice idea to have such an analysis, but I don't think is feasible. On Thu, 9 Apr 2020 at 04:29, Caleb Donovick <donov...@cs.stanford.edu> wrote: > This would almost certainly break my code. As a DSL developer I do a lot > of (exec | eval | introspection | ... ) shenanigans, that would make doing > liveness analysis undecidable. > > On Wed, Apr 8, 2020 at 10:51 AM Andrew Barnert via Python-ideas < > python-ideas@python.org> wrote: > >> On Apr 8, 2020, at 09:57, Guido van Rossum <gu...@python.org> wrote: >> > >> > >> > Look at the following code. >> > >> > def foo(a, b): >> > x = a + b >> > if not x: >> > return None >> > sleep(1) # A calculation that does not use x >> > return a*b >> > >> > This code DECREFs x when the frame is exited (at the return statement). >> But (assuming) we can clearly see that x is not needed during the sleep >> (representing a big calculation), we could insert a "del x" statement >> before the sleep. >> > >> > I think our compiler is smart enough to find out *some* cases where it >> could safely insert such del instructions. >> >> It depends on how much you’re willing to break and still call it “safely”. >> >> def sleep(n): >> global store >> store = inspect.current_frame().f_back.f_locals['x'] >> >> This is a ridiculous example, but it shows that you can’t have all of >> Python’s dynamic functionality and still know when locals are dead. And >> there are less ridiculous examples with different code. If foo actually >> calls eval, exec, locals, vars, etc., or if it has a nested function that >> nonlocals x, etc., how can we spot that at compile time and keep x alive? >> >> Maybe that’s ok. After all, that code doesn’t work in a Python >> implementation that doesn’t have stack frame support. Some of the other >> possibilities might be more portable, but I don’t know without digging in >> further. >> >> Or maybe you can add new restrictions to what locals and eval and so on >> guarantee that will make it ok? Some code will break, but only rare >> “expert” code, where the authors will know how to work around it. >> >> Or, if not, it’s definitely fine as an opt-in optimization: decorate the >> function with @deadlocals and that decorator scans the bytecode and finds >> any locals that are dead assuming there’s no use of locals/eval/cells/etc. >> and, because you told it to assume that by opting in to the decorator, it >> can insert a DELETE_FAST safely. >> >> People already do similar things today—e.g., I’ve (only once in live >> code, but that’s still more than zero) used a @fastconst decorator that >> turns globals into consts on functions that I know are safe and are >> bottlenecks, and this would be no different. And of course you can add a >> recursive class decorator, or an import hook (or maybe even a command line >> flag or something) that enables it everywhere (maybe with a @nodeadlocals >> decorator for people who want it _almost_ everywhere but need to opt out >> one or two functions). >> >> Did Victor Stinner explore this as one of the optimizations for FAT >> Python/PEP 511/etc.? Maybe not, since it’s not something you can insert a >> guard, speculatively do, and then undo if the guard triggers, which was I >> think his key idea. >> >> _______________________________________________ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/OIGCRV464VJW3FRRBBK25XSNQYGWID7N/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/DSIMIUM6QCUMC2GRTFV646KVWYIR45DR/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VF2J6X6KS7XRKBSHXZEGD3ABRIKLKDM3/ Code of Conduct: http://python.org/psf/codeofconduct/
