[Tim Peters] >> If P3K retains them [__del__]-- or maybe even before --we should >> consider taking "the Java dodge" on this one. That is, decree that >> henceforth a __del__ method will get invoked by magic at most >> once on any given object O, no matter how often O is resurrected.
[Phillip J. Eby] > How does that help? You have to dig into Armin's example (or read his explanation): every time __del__ is called on one of his X objects, it creates a cycle by binding sys.exec_info()[2] to the local vrbl `e_tb`. `self` is reachable from that cycle, so self's refcount does not fall to 0 when __del__ returns. The object is resurrected. When cyclic gc next runs, it determines that the cycle is trash, and runs around decref'ing the objects in the cycle. That eventually makes the refcount on the X object fall to 0 again too, but then its __del__ method also runs again, and creates an isomorphic cycle, resurrecting `self` again. Etc. Armin didn't point this out explicitly, but it's important to realize that gc.garbage remains empty the entire time you let his program run. The object with the __del__ method isn't _in_ a cycle here, it's hanging _off_ a cycle, which __del__ keeps recreating. Cyclic gc isn't inhibited by a __del__ on an object hanging off a trash cycle (but not in a trash cycle itself), but in this case it's ineffective anyway. If __del__ were invoked only the first time cyclic gc ran, the original cycle would go away during the next cyclic gc run, and a new cycle would not take its place. > Doesn't it mean that we'll have to have some way of keeping track of > which items' __del__ methods were called? Yes, by hook or by crook; and yup too, that may be unattractive. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
