[Python-ideas] PEP 3151 - Reworking the OS and IO exception hierarchy (again)

[Georg Brandl]

Am 11.11.2010 13:03, schrieb Nick Coghlan:
> On Thu, Nov 11, 2010 at 7:09 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> Antoine Pitrou wrote:
>>>
>>> Hello,
>>>
>>> Georg (who manages the 3.2 release) suggested that I push PEP 3151 (*)
>>> in the hope that it can get in before the 3.2 feature freeze.
>>>
>>> Is there any consensus that PEP 3151 should get in 3.2, or even that it
>>> should get in at all?  If there's some process issue that I'm missing,
>>> I'd be glad to know about it.
>>>
>>> (*) http://www.python.org/dev/peps/pep-3151/
>>
>> In its current state, I don't think it should go in 3.2:
>>
>> There are a couple of cases where you remove more error classes
>> which will cause existing code to catch more errors than what
>> the code was designed for, e.g. catching socket.error will
>> now also catch all IOErrors, code catching OSErrors will now
>> also catch IOErrors.
>>
>> By making the scope of an except clause larger, you alter the
>> semantics of programs using the more fine-grained hierarchies
>> in ways which are both difficult to detect and harder to work
>> around.
> 
> This issue is addressed directly in the PEP by the "Compatibility
> Strategy" section. Code which checks errno will not suddenly start
> catching additional exceptions due to the merger of IOError and
> OSError.
> 
> However, I agree with you that the PEP would benefit from keeping
> socket.error, select.error and mmap.error as separate IOError
> subclasses. Existing code may legitimately be catching those in try
> blocks that include other unrelated operations that may raise IOError.

Agreed.  Let's keep the potential incompatibilities and surprises to a
minimum.  After all, behavior changes in this area will only show up
in the exceptional case, which depending on the context will not be
triggered frequently, and its test coverage is often low due to the
relative difficulty of mocking these things.

cheers,
Georg