On Thu, Apr 7, 2011 at 6:43 PM, M.-A. Lemburg <mal@egenix.com> wrote:
The main problem with the PEP is the proposal to flatten existing exception class hierarchies, e.g. making socket.error the same as IOError.
This introduces very subtle compatibility problems with code that uses the flattened exception classes in separate except branches, e.g.
try: ... except socket.error: ... except IOError: ...
With the PEP implemented, the above code would never get to execute the IOError branch and instead divert all error handling to the socket.error branch which may well not be aware of all the extra cases it now has to handle.
I think that this part of the PEP should not be accepted.
I think EnvironmentError, WindowsError, VMSError, OSError, mmap.error and select.error should definitely all be merged with IOError, as they aren't used consistently enough to make handling them differently reliable even in current code. socket.error is the one case where that argument isn't quite as strong, since the socket module is reasonably consistent about raising it over a base IOError. I think it would be useful to look at which errno values may currently be associated with socket.error, and merge it with the new exception at that level in the type heirarchy. For example, taking the draft heirarchy at http://www.python.org/dev/peps/pep-3151/#new-exception-classes, then the merger that makes the most sense might be "socket.error = ConnectionError". Alternatively, and if necessary, socket.error could be grandfathered in to cover an appropriate subset of errno values via multiple inheritance: class error(ConnectionError, TimeoutError): pass Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia