[Python-ideas] PEP 3151 - Reworking the OS and IO exception hierarchy (again)

Nick Coghlan ncoghlan at gmail.com
Thu Nov 11 14:50:36 CET 2010


On Thu, Nov 11, 2010 at 11:08 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Most socket I/O errors use different errnos (socket-specific errnos such
> as ECONNRESET, etc.), so merging the exception classes wouldn't change
> anything for careful code which checks the errno.
>
> As for mmap.error, I think it's a design mistake in the first place,
> since mmap'ed files are not consistently different from normal files.
>
> As for select.error, the way the select module itself is generally
> inconsistent in which exceptions it raises also makes me think it is a
> design or implementation bug. The fact that it doesn't even inherit
> EnvinromentError reinforces that feeling.
>
> More fundamentally, the effort to create a detailed IO exception
> hierarchy is much less useful if we keep islands such as socket.error,
> mmap.error, since those errors won't benefit. The PEP only achieves
> maximum usefulnesss if it can leverage a single IO exception base
> class.
>
>
> That said, it is obvious that this PEP can raise compatibility concerns
> for uncaring code (code which is already poorly written in the first
> place). There's no way to reorganize the exception hierarchy without
> risking such issues. Actually, even without reorganizing the exception
> hierarchy, it often happens that we casually change the exception type
> raised by a given function, because we think the old behaviour was
> mistaken. Nobody apparently blames us for doing that (perhaps they
> are not reading python-checkins carefully enough :-)).
>
> So, as a data point, carefully merging the exception classes (all of
> OSError, IOError, EnvinronmentError, WindowsError, VMSError,
> socket.error, mmap.error and select.error) doesn't produce any error in
> the regression test suite. You can look at the SVN branch named
> "pep-3151" for that.

Perhaps the better approach would be to explicitly list out the
exceptions being merged in the compatibility section and state which
case applies:

"Code that cares should already be checking the errno attribute":
socket.error, OSError, WindowsError, VMSError

"Already cannot be reliably handled distinct from IOError due to the
way the affected modules are implemented": mmap.error, select.error

Then we can state that any exception clause which changes scope due to
the new merger into IOError was already broken and we're just slightly
changing exactly how it is broken.

That said, didn't we originally punt on this PEP for 3.2 due to the
moratorium rather than due to any lack of time to get it done?

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia



More information about the Python-ideas mailing list