Mention the interesting idea of modifiying IOError.__new__

(instead of the PyErr_SetFromErrno functions)

pep-3151.txt

@@ -440,22 +440,19 @@ Implementation
 
 Since it is proposed that the subclasses are raised based purely on the
 value of ``errno``, little or no changes should be required in extension
-modules (either standard or third-party).  As long as they use the
-``PyErr_SetFromErrno()`` family of functions (or the
-``PyErr_SetFromWindowsErr()`` family of functions under Windows), they
-should automatically benefit from the new, finer-grained exception classes.
+modules (either standard or third-party).
 
-Library modules written in Python, though, will have to be adapted where
-they currently use the following idiom (seen in ``Lib/tempfile.py``)::
+The first possibility is to adapt the ``PyErr_SetFromErrno()`` family
+of functions (``PyErr_SetFromWindowsErr()`` under Windows) to raise the
+appropriate ``IOError`` subclass.  This wouldn't cover, however, Python
+code raising IOError directly, using the following idiom (seen in
+``Lib/tempfile.py``)::
 
     raise IOError(_errno.EEXIST, "No usable temporary file name found")
 
-Fortunately, such Python code is quite rare since raising OSError or IOError
-with an errno value normally happens when interfacing with system calls,
-which is usually done in C extensions.
-
-If there is popular demand, the subroutine choosing an exception type based
-on the errno value could be exposed for use in pure Python.
+A second possibility, suggested by Marc-Andre Lemburg, is to adapt
+``IOError.__new__`` to instantiate the appropriate subclass.  This would
+have the benefit of also covering Python code such as the above.
 
 
 Possible objections