"A.M. Kuchling" wrote: > > ... > > An experimental step has been made toward fixing this problem. When > compiling Python, the -with-cycle-gc (XXX correct option flag?) option > can be specified. This causes a cycle detection algorithm to be > periodically executed, which looks for inaccessible cycles and deletes > the objects involved. I propose (without any investigation into the difficulty of implementation) that import cyclicgc should turn on the -with-cycle-gc flag. Then you could do a import cyclicgc import someDOM And not worry about cycles. If it's too slow, you remove the line and take responsibility for cycle checking. The important thing is that you don't have to tell YOUR USERS to turn on GC in order for your code to work. I think that this model will get more people actively using (and depending upon!) GC and thus give us a better idea about usage patterns, stability and performance. This is especially important in the beta period when we are trying to shake out bugs. Really, this comes back to Greg's point that we should not have incompatible sub-languages running around. A module depends on the feature or it doesn't. The end-user should not be responsible for knowing whether any module in a whole program needs GC. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski
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