On Thu, Jul 05, 2007 at 12:05:01PM +0200, Guido van Rossum wrote: > On 7/5/07, Gregory P. Smith <[EMAIL PROTECTED]> 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 socket.error. 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. -Greg _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
