urllib goes to goes to some trouble to ensure that it raises IOError, even when the underlying exception comes from another module.[*] I'm wondering if it would make sense to just have those modules' exceptions inherit from IOError. In particular, should socket.error, ftp.Error and httplib.HTTPException (used in Py3K) inherit from IOError? I'm also wondering whether it would be acceptable to change the details of the exceptions. For example, could raise IOError, ('ftp error', msg), sys.exc_info()[2] be reworded, or is there there too much risk that someone is checking for an "errno" of 'ftp error'? [*] This isn't a heavily tested path; some actually fail with a TypeError since 2.5, because IOError no longer accepts argument tuples longer than 3. http://bugs.python.org/issue1209 Fortunately, this makes me less worried about changing the contents of the specific attributes to something more useful... -jJ
Shouldn't these all inherit from EnvironmentError? Or should EnvironmentError and IOError be the same thing perhaps? --Guido On 9/26/07, Jim Jewett <jimjjewett@gmail.com> wrote:
urllib goes to goes to some trouble to ensure that it raises IOError, even when the underlying exception comes from another module.[*] I'm wondering if it would make sense to just have those modules' exceptions inherit from IOError.
In particular, should socket.error, ftp.Error and httplib.HTTPException (used in Py3K) inherit from IOError?
I'm also wondering whether it would be acceptable to change the details of the exceptions. For example, could
raise IOError, ('ftp error', msg), sys.exc_info()[2]
be reworded, or is there there too much risk that someone is checking for an "errno" of 'ftp error'?
[*] This isn't a heavily tested path; some actually fail with a TypeError since 2.5, because IOError no longer accepts argument tuples longer than 3. http://bugs.python.org/issue1209 Fortunately, this makes me less worried about changing the contents of the specific attributes to something more useful...
-jJ _______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Jim Jewett wrote:
In particular, should socket.error, ftp.Error and httplib.HTTPException (used in Py3K) inherit from IOError?
I'd say that if they incorporate a C library result code they should inherit from IOError, or if they incorporate a system call result code they should inherit from OSError. Otherwise they should inherit from EnvironmentError. I don't think there's any point in simply catching one of these and re-wrapping it in the library's own exeption class, but if such wrapping is done, it should inherit from EnvironmentError as well. It's convenient to be able to catch EnvironmentError and get anything that is caused by circumstances outside the program's control. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+
How about making IOError, OSError and EnvironmentError all aliases for the same thing? The distinction is really worthless historical baggage. On 9/26/07, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Jim Jewett wrote:
In particular, should socket.error, ftp.Error and httplib.HTTPException (used in Py3K) inherit from IOError?
I'd say that if they incorporate a C library result code they should inherit from IOError, or if they incorporate a system call result code they should inherit from OSError. Otherwise they should inherit from EnvironmentError.
I don't think there's any point in simply catching one of these and re-wrapping it in the library's own exeption class, but if such wrapping is done, it should inherit from EnvironmentError as well.
It's convenient to be able to catch EnvironmentError and get anything that is caused by circumstances outside the program's control.
-- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+ _______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On 9/27/07, Guido van Rossum <guido@python.org> wrote:
How about making IOError, OSError and EnvironmentError all aliases for the same thing? The distinction is really worthless historical baggage.
+1 from me. Should OSError and IOError become aliases to EnvironmentError? I assume WindowsError and VMSError will just directly subclass which ever exception sticks around. And should we bother with a PendingDeprecationWarning for IOError or OSError? Or just have a Py3K warning for them and not worry about their removal in the 2.x series and just let 2to3 handle the transition? -Brett
On 27 Sep 2007, 21:23:58, Brett Cannon wrote:
Should OSError and IOError become aliases to EnvironmentError? I assume WindowsError and VMSError will just directly subclass which ever exception sticks around.
And should we bother with a PendingDeprecationWarning for IOError or OSError? Or just have a Py3K warning for them and not worry about their removal in the 2.x series and just let 2to3 handle the transition?
Am I missing something, as I thought Py2K was supposed to throw backwards compatability to the wind in favor of doing the "Right Thing"? If so, can't we lose the proposed OSError and IOError aliases altogether, and just keep EnvironmentError? Perhaps "EnvironmentError" is a bit long to type in all the places OSError and IOError are used, I personally like the look of OSError and IOError better in my code. I vote for a shorter name for EnvironmentError, e.g. EMError. just my 2c, Graham
-Brett _______________________________________________ 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/graham.horler%40gmail.com
I'd be happy to make them all IOError. 2to3 can clean this up. On 9/27/07, Graham Horler <graham.horler@gmail.com> wrote:
On 27 Sep 2007, 21:23:58, Brett Cannon wrote:
Should OSError and IOError become aliases to EnvironmentError? I assume WindowsError and VMSError will just directly subclass which ever exception sticks around.
And should we bother with a PendingDeprecationWarning for IOError or OSError? Or just have a Py3K warning for them and not worry about their removal in the 2.x series and just let 2to3 handle the transition?
Am I missing something, as I thought Py2K was supposed to throw backwards compatability to the wind in favor of doing the "Right Thing"?
If so, can't we lose the proposed OSError and IOError aliases altogether, and just keep EnvironmentError?
Perhaps "EnvironmentError" is a bit long to type in all the places OSError and IOError are used, I personally like the look of OSError and IOError better in my code. I vote for a shorter name for EnvironmentError, e.g. EMError.
just my 2c, Graham
-Brett _______________________________________________ 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/graham.horler%40gmail.com
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Is IOError is the right name to use? OSError is raised for things that are not IO such as subprocess, dlopen, system. Nobody likes typing out EnvironmentError and dislike the suggestion of EMError, should it just be OSError? errno values are after all OS specific. -gps On 9/27/07, Guido van Rossum <guido@python.org> wrote:
I'd be happy to make them all IOError. 2to3 can clean this up.
On 9/27/07, Graham Horler <graham.horler@gmail.com> wrote:
On 27 Sep 2007, 21:23:58, Brett Cannon wrote:
Should OSError and IOError become aliases to EnvironmentError? I assume WindowsError and VMSError will just directly subclass which ever exception sticks around.
And should we bother with a PendingDeprecationWarning for IOError or OSError? Or just have a Py3K warning for them and not worry about their removal in the 2.x series and just let 2to3 handle the transition?
Am I missing something, as I thought Py2K was supposed to throw backwards compatability to the wind in favor of doing the "Right Thing"?
If so, can't we lose the proposed OSError and IOError aliases altogether, and just keep EnvironmentError?
Perhaps "EnvironmentError" is a bit long to type in all the places OSError and IOError are used, I personally like the look of OSError and IOError better in my code. I vote for a shorter name for EnvironmentError, e.g. EMError.
just my 2c, Graham
-Brett _______________________________________________ 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/graham.horler%40gmail.com _______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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/greg%40krypto.org
Gregory P. Smith wrote:
Is IOError is the right name to use? OSError is raised for things that are not IO such as subprocess, dlopen, system.
The trouble with either of these is that the class of errors we're talking about don't necessarily come directly from the OS or I/O library. Often I raise my own EnvironmentError instances for things which don't have any associated OS error code but are nonetheless environment-related, such as an error in a file format. I don't reuse IOError or OSError because I feel as though I ought to supply an errno with these, but there isn't any. I suppose we could pick one of these and make it official that it's okay to instantiate it without an errno. But it's hard to decide which one, because they both sound too narrow in scope. I don't like EMError either, btw. Maybe EnvError? Although that sounds like it has something to do with the unix environment variables. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+
On 9/27/07, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Gregory P. Smith wrote:
Is IOError is the right name to use? OSError is raised for things that are not IO such as subprocess, dlopen, system.
The trouble with either of these is that the class of errors we're talking about don't necessarily come directly from the OS or I/O library.
Often I raise my own EnvironmentError instances for things which don't have any associated OS error code but are nonetheless environment-related, such as an error in a file format.
I don't reuse IOError or OSError because I feel as though I ought to supply an errno with these, but there isn't any.
I suppose we could pick one of these and make it official that it's okay to instantiate it without an errno. But it's hard to decide which one, because they both sound too narrow in scope.
I don't like EMError either, btw. Maybe EnvError? Although that sounds like it has something to do with the unix environment variables.
ExternalError? Pretty vague though. -- Adam Olsen, aka Rhamphoryncus
Greg Ewing writes:
Gregory P. Smith wrote:
Is IOError is the right name to use? OSError is raised for things that are not IO such as subprocess, dlopen, system.
The trouble with either of these is that the class of errors we're talking about don't necessarily come directly from the OS or I/O library.
Agree, but I think this is a case where practicality beats purity. +1 for OSerror.
On 9/28/07, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Greg Ewing writes:
Gregory P. Smith wrote:
Is IOError is the right name to use? OSError is raised for things that are not IO such as subprocess, dlopen, system.
The trouble with either of these is that the class of errors we're talking about don't necessarily come directly from the OS or I/O library.
Agree, but I think this is a case where practicality beats purity.
+1 for OSerror.
The OS is a somewhat troublesome abstraction boundary. I/O is a more general concept (and PPBP). +1 for IOError. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On 9/28/07, Guido van Rossum <guido@python.org> wrote:
On 9/28/07, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Greg Ewing writes:
Gregory P. Smith wrote:
Is IOError is the right name to use? OSError is raised for things that are not IO such as subprocess, dlopen, system.
The trouble with either of these is that the class of errors we're talking about don't necessarily come directly from the OS or I/O library.
Agree, but I think this is a case where practicality beats purity.
+1 for OSerror.
The OS is a somewhat troublesome abstraction boundary. I/O is a more general concept (and PPBP). +1 for IOError.
What is PPBP? -Brett
On 9/28/07, Brett Cannon <brett@python.org> wrote:
On 9/28/07, Guido van Rossum <guido@python.org> wrote:
On 9/28/07, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Greg Ewing writes:
Gregory P. Smith wrote:
Is IOError is the right name to use? OSError is raised for things that are not IO such as subprocess, dlopen, system.
The trouble with either of these is that the class of errors we're talking about don't necessarily come directly from the OS or I/O library.
Agree, but I think this is a case where practicality beats purity.
+1 for OSerror.
The OS is a somewhat troublesome abstraction boundary. I/O is a more general concept (and PPBP). +1 for IOError.
What is PPBP?
Typo for PBP : Practicality Beats Purity. :) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On 9/27/07, Guido van Rossum <guido@python.org> wrote:
How about making IOError, OSError and EnvironmentError all aliases for the same thing? The distinction is really worthless historical baggage.
Wouldn't it also be nice to have some subclasses of IOError like FileNotFoundError, IOPermissionError and EOFError? Often that would be easier than having to use the errno attribute to find out the exact cause. -- mvh Björn
I suspect that the use case for those errors is far less than you think. On 9/27/07, BJörn Lindqvist <bjourne@gmail.com> wrote:
On 9/27/07, Guido van Rossum <guido@python.org> wrote:
How about making IOError, OSError and EnvironmentError all aliases for the same thing? The distinction is really worthless historical baggage.
Wouldn't it also be nice to have some subclasses of IOError like FileNotFoundError, IOPermissionError and EOFError? Often that would be easier than having to use the errno attribute to find out the exact cause.
-- mvh Björn
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
How about making IOError, OSError and EnvironmentError all aliases for the same thing? The distinction is really worthless historical baggage.
To my mind, the distinction is that IOError and OSError have an attribute for the error code, and the code found there has a well-defined meaning (C library error code and system call error code respectively), whereas EnvironmentError is more general. While it might be possible to merge them all together on Unix-like systems, that wouldn't necessarily be true on all platforms -- the IOError and OSError codes might belong to different domains. Although I suppose you could have another attribute to distinguish them if necessary. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+
participants (9)
-
Adam Olsen -
BJörn Lindqvist -
Brett Cannon -
Graham Horler -
Greg Ewing -
Gregory P. Smith -
Guido van Rossum -
Jim Jewett -
Stephen J. Turnbull