On Fri, Nov 12, 2010 at 1:03 AM, M.-A. Lemburg <mal@egenix.com> wrote:
There's nothing wrong with code such as this:
try: ... except socket.error: print 'Network problem' except IOError: print 'File I/O problem' except OSError: print 'File system problem'
You probably have a different use of try-except in mind. Those exception handling blocks are used at various levels in an application and the code run between try-except may well be dealing with sockets and file I/O, but require two different sets of problem resolution or reporting implementations.
The PEP breaks such code.
No, that's the kind of code we're saying is already subtly broken, and we're just changing the way it is broken to be far more obvious (instead of *sometimes* printing the wrong message based on exactly what went wrong, it will instead consistently print the message associated with whichever of IOError and OSError is listed first). The standard library may have been consistent about IOError vs OSError at one point in time, but that time is in the past. Any code which doesn't catch (or ignore) them both and treat them as equivalent to each other is either already broken (if the try block contains code which may raise either exception) or won't be affected by the proposal in the PEP (if the try block is guaranteed to raise only the exception type already caught by the try block). Trying to restore a consistent distinction between them is even more of compatibility problem than simply giving up and merging them. I thought the PEP already made this point, but it may not be as clear if you don't already agree with the conclusion. There is a slightly better case for keeping socket.error around since we've been fairly consistent in having the networking code raise that rather than a bare IOError. However, even there the value of the distinction is blurring, since the other layers of the IO stack will still raise IOError. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia