[Python-Dev] Adding NetworkIOError for bug 1706815

Gregory P. Smith greg at electricrain.com
Sat Jul 7 01:01:10 CEST 2007

On Thu, Jul 05, 2007 at 12:05:01PM +0200, Guido van Rossum wrote:
> On 7/5/07, Gregory P. Smith <greg at electricrain.com> wrote:
> >On Wed, Jul 04, 2007 at 11:03:42AM +0200, Guido van Rossum wrote:
> >> Why not simply inherit socket.error from EnvironmentError?
> >
> >True, that would be simpler; is it enough?  If we avoid adding the new
> >exception, I really think it should inherit from IOError, not
> >EnviromnentError because sockets are I/O.  urllib2.URLError was
> >already a child of IOError; doing the same to to socket.error makes
> >sense.
> OTOH, when os.read() returns an error, os.error (OSError) is raised.
> Is that not I/O?
> IMO this is all hairsplitting, and the exact inheritance hierarchy for
> these doesn't matter much -- nobody is going to write a handler that
> treats OSError or socket.error different than IOError.

Ah.  Given all that, the point of a NetworkIOError is moot.  I had
assumed read would raise an IOError but hadn't read the code.  Looks
like fileobject.c's file_read() raises IOError as I expected but
posixmodule.c's read() raises OSError (fair enough, its the os module).

Since socket objects are treated like file objects in many cases I
think IOError would be a more appropriate parent than
EnvironmentError.  There was a case at work recently that started me
down the path of looking at this where code caught IOError but not

Any objects to me just having socket.error inherit from IOError?

> >PS for the person complaining that the url didn't work.  blame
> >   sourceforge and go look the bug up by id yourself.  nothing i can
> >   do about that.
> Try python.org/sf/1706815
> --Guido

ooo handy.  thanks.


More information about the Python-Dev mailing list