On 24 July 2010 22:31, Gregory P. Smith <greg@krypto.org> wrote:
On Wed, Jul 21, 2010 at 12:34 PM, Antoine Pitrou <solipsis@pitrou.net>wrote:
Hello,
I would like to propose the following PEP for feedback and review. Permanent link to up-to-date version with proper HTML formatting: http://www.python.org/dev/peps/pep-3151/
Thank you,
Antoine.
[...]
+1 in on this whole PEP!
+1 from me too. Michael
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
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas