This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: IOBaseError
Type: enhancement Stage:
Components: Interpreter Core Versions: Python 3.0
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, gregory.p.smith, kxroberto
Priority: normal Keywords:

Created on 2006-05-03 12:04 by kxroberto, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (7)
msg61230 - (view) Author: kxroberto (kxroberto) Date: 2006-05-03 12:04
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
msg65417 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-04-12 20:47
Something like this was done in 2.5.
msg65420 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2008-04-12 21:31
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?
msg65421 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-04-12 21:36
Yes, that'd make sense. Ask on python-dev, though.
msg65424 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2008-04-12 21:57
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)
msg65437 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2008-04-13 07:43
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).
msg65442 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-04-13 12:29
Py3k then?
History
Date User Action Args
2022-04-11 14:56:17adminsetgithub: 43312
2008-04-14 08:48:21arigosetnosy: - arigo
2008-04-13 12:29:12benjamin.petersonsetmessages: + msg65442
versions: + Python 3.0, - Python 2.6
2008-04-13 07:43:41arigosetnosy: + arigo
messages: + msg65437
2008-04-12 21:57:08gregory.p.smithsetmessages: + msg65424
2008-04-12 21:36:48benjamin.petersonsetstatus: open -> closed
resolution: fixed
messages: + msg65421
2008-04-12 21:33:47gregory.p.smithsetstatus: closed -> open
resolution: fixed -> (no value)
2008-04-12 21:31:56gregory.p.smithsetnosy: + gregory.p.smith
messages: + msg65420
versions: + Python 2.6
2008-04-12 20:48:46benjamin.petersonsetstatus: open -> closed
2008-04-12 20:47:28benjamin.petersonsetresolution: fixed
messages: + msg65417
nosy: + benjamin.peterson
2006-05-03 12:04:10kxrobertocreate