[Python-ideas] PEP 3151: Reworking the OS and IO exception hierarchy

[Nick Coghlan]

I read this while you were working on it in the sandbox - +1 in
principle, but the devil is obviously going to be in the details.

On Thu, Jul 22, 2010 at 5:34 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Step 1: coalesce exception types
> ================================
>
> The first step of the resolution is to coalesce existing exception types.
> The extent of this step is not yet fully determined.  A number of possible
> changes are listed hereafter:
>
> * alias both socket.error and select.error to IOError
> * alias mmap.error to OSError
> * alias IOError to OSError
> * alias WindowsError to OSError
>
> Each of these changes doesn't preserve exact compatibility, but it does
> preserve *useful compatibility* (see "compatibility" section above).
>
> Not only does this first step present the user a simpler landscape, but
> it also allows for a better and more complete resolution of step 2
> (see "Prerequisite" below).

Another idea along these lines would be to coalesce the builtin
exceptions at the EnvironmentError level.

That is, the top of the revised hierarchy would look like:

   +-- IOError
       +-- io.BlockingIOError
       +-- io.UnsupportedOperation (also inherits from ValueError)

IOError would be aliased as EnvironmentError, OSError, WindowsError,
socket.error, mmap.error and select.error

Coalescing WindowsError like that would mean the "winerr" attribute
would be present on all platforms, just set to "None" if the platform
isn't Windows. (errno, filename and strerror can all already be None,
as will often be the case when IOError is raised directly by Python
code).

select.error (now just an alias for IOError) would also grow the
common IOError attributes.

I'm suggesting IOError as the name based on your survey of what
standard libraries currently raise (i.e. the vast majority of them use
IOError rather than one of the other names). EnvironmentError would
probably be more accurate, but IOError is more common and easier to
type (and from the interpreter's point of view, any manipulation of
the underlying OS can be viewed as a form of I/O, even if it involves
accessing the process table or the environment variables or the
registry rather than the filesystem or network).

Also, there should be a helper function (probably in the os module)
that given an errno value will create the appropriate IOError
subclass.

Regards,
Nick.

P.S. I want to let the idea kick around in my brain for a while before
offering suggestions for possible useful IOError subclasses. Note that
we don't need to create subclasses for *everything* - errors without a
specific subclass can fall back to the basic IOError. Still, I expect
many bikesheds will be painted a wide variety of colours before this
discussion is done ;)

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