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

[Michael Foord]

On 24 July 2010 22:31, Gregory P. Smith <greg at krypto.org> wrote:

>
> On Wed, Jul 21, 2010 at 12:34 PM, Antoine Pitrou <solipsis at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>


-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100731/7786ed3c/attachment.html>