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