A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2003-April/034597.html below:

[Python-Dev] Garbage collecting closures

[Python-Dev] Garbage collecting closures [Python-Dev] Garbage collecting closuresPaul Prescod paul@prescod.net
Mon, 14 Apr 2003 14:41:31 -0700
Guido van Rossum wrote:
> Paul, would finalizers have been run if you had included an explicit
> gc.collect() call?
> 
> If so, I'd say that a sufficiently portable rule is that you can't
> trust finalizers to run until GC is run (in Jython, gc.collect() isn't
> how it is invoked though).

Yes, now that I know to try it, gc.collect() would have fixed the problem.

But I'm not sure where I would have learned to do so. The documentation 
for __del__ is out of date.

  * http://www.python.org/doc/2.3a2/ref/customization.html

The documentation lists a variety of reasons that __del__ might not get 
called (it doesn't claim to be exhaustive but it does list some cases 
that I consider pretty obscure). It doesn't list nested recursive functions.

One strategy is to update the __del__ and gc documentation to add this 
case. Another strategy is to update the __del__ documentation to say: 
"if you want this to be executed deterministically in CPython, call 
gc.collect()". Or both.

  Paul Prescod




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4