[Python-Dev] Silencing IO errors on del/dealloc?

[Guido van Rossum]

On Sun, Feb 22, 2009 at 11:32 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Guido van Rossum <guido <at> python.org> writes:
>> OTOH the is a much larger category of false positives, where a close()
>> call raise an exception for some spurious reason (see the quoted
>> comment) but no harm is done; in the past the tracebacks printed for
>> __del__ by default have caused nothing but confuse users (who think
>> something is seriously wrong but have no way to debug it).
>>
>> The svn history of those lines may have more pointers.
>
> Well this code dates back to the first checkin in the py3k branch. Apparently
> the old p3yk branch is not there anymore...

OK, then we'll just have to understand the big comment in the code.

> I understand the missing globals on shutdown problem, but the error may also be
> a legitimate programming error, where a close() implementation fails for
> whatever reason. At least displaying the error may encourage the programmer to
> strengthen his implementation.
>
> How about the following compromise:
>
>    try:
>        closed = self.closed
>    except:
>        # Object is in an unusable state, don't attempt anything
>        pass
>    else:
>        if not closed:
>            self.close()

No. Trust me. It is not always possible to strengthen the
implementation. (At least not until we get rid of the "replace all
globals with None upon module deletion" rule.) Your "legitimate
programming error" is purely hypothetical, while the unactionable,
confusing traceback caused by missing globals is real. If people want
an exception from close() they can call it explicitly or use a context
manager. When a file is closed implicitly by __del__, there is a
chance of an impossible-to-avoid spurious traceback. I have dealt with
such tracebacks in real life and there is nothing that can be done
about them except ignore them. If you don't ignore them, users living
1000s of miles away and years later than the original programmer will
be upset by spurious tracebacks that worry them to death.

If you want to ensure buffers are flushed, why not call self.flush()
for writable files outside the try/except? If flush() fails it *is* a
real problem.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)