Working my way through the unqualified except: clauses, I found one in fileinput.py that looks very straightforward:

try: os.unlink(backupfilename) except: pass

To make sure that OSError was all that could be raised I started looking at what values backupfilename could assume. Then I started looking at self._backupfilename. This weird beast takes on values of three distinct types: None, 0, and various strings.

If you read the context of the try/except clause, it's clear that it can't be None or 0 at that point.

While it's not technically broken, is this something worth fixing? My inclination is to just add OSError to the except clause and let someone else worry about fixing something that's ugly but not really broken.

Note that None and 0 are used for the same purpose. I think 0 is used to avoid referencing any globals in code called from the __del__ method. You might change the code to use "" instead of None or 0, but I wouldn't bother. --Guido van Rossum (home page: http://www.python.org/~guido/)