Maybe there should be a common base Exception class
"IOBaseError" for :   EnvironmentError(IOError,
OSError),  EOFError, socket.error, socket.sslerror,
ftplib.all_errors, etc.  

Nice as it and not all IO sublibs have to be imported
to catch such errors.

See a recent need in patch #1481032 . I have this need
very often in mixed IO apps and am forced to except
naked (and being exposed to pythonic AttribError's etc. )

-robert

Something like this was done in 2.5.

I don't think so.

socket.error has been changed to inherit from IOError in 2.6 (and thus
socket.sslerror which inherits from socket.error).

EOFError has not changed.

ftplib.all_errors is already a tuple of (ftplib.Error, socket.error,
IOError, EOFError) which demonstrates the issue...

Anyways there was discussion on python-dev around the time I made
socket.error extend IOError.  Adding a new exception to the heirarchy
was frowned upon.  EnvironmentError is already suitable for that task.

Perhaps EOFError should extend EnvironmentError as well?

Yes, that'd make sense. Ask on python-dev, though.

The problem with EOFError as a child of EnvironmentError is that it
wouldn't conform to EnvironmentError's standard 2-tuple or 3-tuple of
args representing errno and the associate string and optionally filename.

So inserting an exception above EnvironmentError would be a solution to
that for EOFError.  Alternatively, EOFError could have some default
2-tuple values and be a child of EnvironmentError.

thoughts or pronouncements anyone?  (asking python-dev now)

This will break many existing applications, no?  I can easily think of
examples of reasonable code that would no longer work as intended. 
What's even worse, breakage might only show up in exceptional cases and
give obscure results (e.g. reporting the wrong problem to the user).

Py3k then?