[Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

Eric V. Smith eric at trueblade.com
Fri Oct 11 12:33:33 CEST 2013


On 10/11/2013 5:00 AM, Antoine Pitrou wrote:
> 
> Let me answer here to Nick's argument on the tracker (made last year,
> before the patch was committed):
> 
>> As with many context managers, a key benefit here is in the priming
>> effect for readers. In this code:
>>
>>     try:
>>        # Whatever
>>     except (A, B, C):
>>        pass
>>
>> the reader doesn't know that (A, B, C) exceptions will be ignored
>> until the end. The with statement form makes it clear before you
>> start reading the code that certain exceptions won't propagate:
>>
>>     with ignored(A, B, C):
>>         # Whatever
> 
> The problem with this argument is that it assumes a very specific idiom:
> i.e. writing long "try" blocks in the purpose of silencing exceptions.
> 
> I'd like to make the following points:
> 
> - when catching an exception, the common (and recommended) behaviour is
>   to do something else - not merely silencing it.  Silencing is not very
>   common in my experience, except in badly written code
> 
> - when catching an exception, it is recommended for the "try" block to
>   be as slim as possible - so that you don't catch other unintended
>   exceptions by mistake. This is a point I already made in PEP 3151.
>   Many exception classes (OSError, KeyError, RuntimeError...) are
>   polysemic.
> 
> The bottom line is that there shouldn't be any long "try" blocks
> followed by a single "except FooException: pass" clause in well-written
> code. The presence of such an idiom is a strong code smell.
> 
> Therefore contextlib.ignore() seems aimed at making it easier to write
> bad code, not good code. I don't think it should exist in the stdlib.

In case anyone wants to look at the original issue, it's
http://bugs.python.org/issue15806

And Antoine has again taught me a new word:
polysemic: having more than one meaning; having multiple meanings

-- 
Eric.


More information about the Python-Dev mailing list