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

Nikolaus Rath Nikolaus at rath.org
Thu Jun 12 02:11:53 CEST 2014

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

Best, -Nikolaus

-- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

         »Time flies like an arrow, fruit flies like a Banana.«

More information about the Python-Dev mailing list