[Python-Dev] issue 9141, finalizers and gc module (original) (raw)

martin at v.loewis.de martin at v.loewis.de
Wed Apr 18 09:11:15 CEST 2012

Well, we specifically decided that objects with del methods that are part of a cycle cannot be run. The same reasoning was applied to generators, if they are in a certain state. What makes iobase so special that its 'close' method can be run even if it is part of a cycle?

It's a hack, and I find it well-documented in iobase.c. It explains
what tricks it has to go through to still invoke methods from tp_del.

Invoking methods in tp_clear I find fairly harmless, in comparison. My only concern is that errors are silently ignored. However, I don't think
this matters in practice, since io objects typically are not part of cycles, anyway.

Why not allow it for all objects, then?

It's allowed for all objects. Why do you think it is not?

It must be opt-in, though. In the IO case, there are certain drawbacks; not being able to report errors is the most prominent one. Any other object implementation will have to evaluate whether to follow the iobase approach, or implement a regular del. I personally consider the resurrection in tp_del a much more serious problem, though, as this goes explicitly against the design of the release procedure. For iobase, it's ok since it can evolve along with the rest of the code base. Any third-party author would have to accept that such approach can break from one Python release to the next.

I wonder why Python couldn't promise to always invoke tp_clear on GC objects; ISTM that this would remove the need for resurrection in tp_del.

At the very least, I think this behaviour (this exception for iobase) merits being explicitly documented.

I find all of this well-documented in iobase.c. If you think anything else needs to be said, please submit patches.

Regards, Martin

More information about the Python-Dev mailing list