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@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@gmail.com | Brisbane, Australia