On Wed, Apr 8, 2020, 10:37 AM Antoine Pitrou email@example.com wrote:
On Wed, 8 Apr 2020 10:18:47 -0700 Guido van Rossum firstname.lastname@example.org wrote:
But when I leave "large" temp objects hanging and give a rip, I already stick in "del" statements anyway. Very rarely, but it happens.
I recall that in the development of asyncio there were a few places where we had to insert del statements, not so much to free a chunk of memory,
to cause some destructor or finalizer to run early enough. (IIRC not
at that moment, but at some later moment even if some Futures are still alive.) Those issues took considerable effort to find, and would conceivably have been prevented by this proposal.
If code relies on life variable analysis for correctness, it implies other Python implementations must implement it with exactly the same results.
As far as I know they all do? The existence of locals() as an API cements this behavior. If you want something to disappear from locals it requires an explicit del. (explicit is better than implicit and all...)
I'd actually accept this optimization in something like micropython where bending rules to fit in mere kilobytes makes sense. But in CPython I want to see serious demonstrated practical benefit before changing this behavior in any file by default. (it could be implemented per file based on a declaration; this would be a bytecode optimization pass)
Python-ideas mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/V6AGHX... Code of Conduct: http://python.org/psf/codeofconduct/