(original) (raw)

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.

Regards

Antoine.


\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com