> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4