[Paul Prescod] > ... > 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. __del__ isn't relevant to your test case, though: if the cycles in question contained any object with a __del__ method, gc would never have reclaimed them (and gc.collect() would have had no effect on them either, other than to move the trash cycles into gc.garbage). You had __del__-free cycles, and then there is indeed no way to predict when they'll get reclaimed. I think that's just life; you wouldn't be any better off in Java or Scheme or anything else. It's always been difficult to guess when the implementation of a thing may involve a cycle under the covers, and closures, generators and new-style classes have created many new opportunities for cycles to appear. I don't expect users to know when they're going to happen! I can't keep them all straight myself. I try to write code that doesn't care, though (avoid __del__ methods; avoid "hiding" critical resources in side effects of what look like simple expressions; arrange for subsystems that can be explicitly told to release critical resources). Ain't always easy.
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