On Wed, Apr 8, 2020 at 10:13 AM Tim Peters <tim.peters@gmail.com> wrote:
My guess:  it would overwhelmingly free tiny objects, giving a
literally unmeasurable (just theoretically provable) memory savings,
at the cost of adding extra trips around the eval loop.  So not really
attractive to me.

Yeah, the extra opcodes might well kill the idea for good.
 
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, but to cause some destructor or finalizer to run early enough. (IIRC not right 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.
 
Which is addressing it at a higher level than any other feedback
you're going to get ;-)  Of course there can be visible consequences
when people are playing with introspection gimmicks.

Plus about all the debugging that would ensue because destructors/finalizers are running *earlier* than expected. ;-)

--
--Guido van Rossum (python.org/~guido)