On Wed, Apr 8, 2020 at 10:13 AM Tim Peters <tim.pet...@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) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/ZRTC2LOEFVGKHXXNVZLLOQSQJ24IAMP2/ Code of Conduct: http://python.org/psf/codeofconduct/
