[Python-Dev] reference leaks, del, and annotations (original) (raw)

Duncan Booth duncan.booth at suttoncourtenay.org.uk
Fri Mar 31 10:12:56 CEST 2006

"Jim Jewett" <jimjjewett at gmail.com> wrote in news:fb6fbf560603301716x13c4cda7x7fd5e462850b5a03 at mail.gmail.com:

As a strawman proposal:

deletes = [(obj.del.cycle, obj) for obj in cycle if hasattr(obj, "del") and hasattr(obj.del, "cycle")] deletes.sort() for (cycle, obj) in deletes: obj.del() Lightweight del methods (such as most resource managers) could set the cycle attribute to True, and thereby ensure that they won't cause unbreakable cycles. Fancier object frameworks could use different values for the cycle attribute. Any object whose del is not annotated will still be at least as likely to get finalized as it is

That doesn't look right to me.

Surely if you have a cycle what you want to do is to pick just one of the objects in the cycle and break the link which makes it participate in the cycle. That should be sufficient to cause the rest of the cycle to collapse with del methods being called from the normal refcounting mechanism.

So something like this:

for obj in cycle: if hasattr(obj, "breakcycle"): obj.breakcycle() break

Every object which knows it can participate in a cycle then has the option of defining a method which it can use to tear down the cycle. e.g. by releasing the resource and then deleting all of its attributes, but no guarantees are made over which obj has this method called. An object with a breakcycle method would have to be extra careful as its methods could still be called after it has broken the cycle, but it does mean that the responsibilities are in the right place (i.e. defining the method implies taking that into account).

More information about the Python-Dev mailing list