On Wed, Apr 8, 2020, 10:37 AM Antoine Pitrou <solipsis@pitrou.net> wrote:
On Wed, 8 Apr 2020 10:18:47 -0700
Guido van Rossum <guido@python.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, 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.

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)

-gps