[Python-ideas] PEP-3151 pattern-matching

[Nick Coghlan]

On Thu, Apr 7, 2011 at 6:43 PM, M.-A. Lemburg <mal at 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 at gmail.com   |   Brisbane, Australia