On Sun, Feb 22, 2009 at 11:32 AM, Antoine Pitrou <solip...@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/) _______________________________________________ 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
