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
_______________________________________________
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
