> If the object having a finalizer doesn't support references to > arbitrary other objects, then the application cannot make this object > be part of a cycle. It could make a subclass, though... > If you need a finalizer, always make two objects. One carries the > resource being encapsulated, and nothing else. The other one is the > object exposed to applications, which has a reference to the resource. That actually sounds like a reasonable solution. I was thinking that __del__ methods on anything referenced from the cycle would prevent collection, not just in the cycle itself, but as you point out, that's not the case. Given that, many of my objections go away. I still may write that Executors module, though, it could be fun... Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
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