The EnvrionmentError hierarchy and common errno test code has bothered me for a while. While I think the namespace pollution concern is valid I would suggest adding "Error" to the end of all of the names (your initial proposal only says "Error" on the end of one of them) as that is consistent with the bulk of the existing standard exceptions and warnings. They are unlikely to conflict with anything other than exceptions people have already defined themselves in any existing code (which could likely be refactored out after we officially define these).
Earlier discussion
==================
While this is the first time such as formal proposal is made, the idea
has received informal support in the past [1]_; both the introduction
of finer-grained exception classes and the coalescing of OSError and
IOError.
The removal of WindowsError alone has been discussed and rejected
as part of another PEP [2]_, but there seemed to be a consensus that the
distinction with OSError wasn't meaningful. This supports at least its
aliasing with OSError.
Moratorium
==========
The moratorium in effect on language builtins means this PEP has little
chance to be accepted for Python 3.2.
Possible alternative
====================
Pattern matching
----------------
Another possibility would be to introduce an advanced pattern matching
syntax when catching exceptions. For example::
try:
os.remove(filename)
except OSError as e if e.errno == errno.ENOENT:
pass
Several problems with this proposal:
* it introduces new syntax, which is perceived by the author to be a heavier
change compared to reworking the exception hierarchy
* it doesn't decrease typing effort significantly
* it doesn't relieve the programmer from the burden of having to remember
errno mnemonics
ugh. no. :) That only works well for single exceptions and encourages less explicit exception types. Exceptions are a class hierarchy, we should encourage its use rather than encouraging magic type specific attributes with conditionals.
-gps