[Python-Dev] Why does IOBase.del call .close? (original) (raw)

Benjamin Peterson benjamin at python.org
Thu Jun 12 02:54:53 CEST 2014

On Wed, Jun 11, 2014, at 17:11, Nikolaus Rath wrote:

MRAB <python at mrabarnett.plus.com> writes: > On 2014-06-11 02:30, Nikolaus Rath wrote: >> Hello, >> >> I recently noticed (after some rather protacted debugging) that the >> io.IOBase class comes with a destructor that calls self.close(): >> >> [0] nikratio at vostro:~/tmp$ cat test.py >> import io >> class Foo(io.IOBase): >> def close(self): >> print('close called') >> r = Foo() >> del r >> [0] nikratio at vostro:~/tmp$ python3 test.py >> close called >> >> To me, this came as quite a surprise, and the best "documentation" of >> this feature seems to be the following note (from the io library >> reference): >> >> "The abstract base classes also provide default implementations of some >> methods in order to help implementation of concrete stream classes. For >> example, BufferedIOBase provides unoptimized implementations of >> readinto() and readline()." >> >> For me, having del call close() does not qualify as a reasonable >> default implementation unless close() is required to be idempotent >> (which one could deduce from the documentation if one tries to, but it's >> far from clear). >> >> Is this behavior an accident, or was that a deliberate decision? >> > To me, it makes sense. You want to make sure that it's closed, releasing > any resources it might be holding, even if you haven't done so > explicitly.

I agree with your intentions, but I come to the opposite conclusion: automatically calling close() in the destructor will hide that there's a problem in the code. Without that automatic cleanup, there's at least a good chance that a ResourceWarning will be emitted so the problem gets noticed. "Silently work around bugs in caller's code" doesn't seem like a very useful default to me...

Things which actually hold system resources (like FileIO) give ResourceWarning if they close in del, so I don't understand your point.

More information about the Python-Dev mailing list