[Python-Dev] Bare except clauses in PEP 348

[Guido van Rossum]

On 8/25/05, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:
>[...] AFAICT, there is no other way to broadly
> catch exceptions not derived from Exception.

But there is rarely a need to do so. I bet you that 99 out of 100 bare
excepts in the stdlib could be replaced by "except Exception" without
breaking anything, since they only expect a wide variety of standard
exceptions, and don't care about string exceptions or user exceptions.

The exception is the first of the two bare except: clauses in code.py.

> The effort is only
> warranted if it makes the code better -- but here nothing is currently
> broken and the new code will be much less attractive and less readable
> (if the changes are done correctly); only 3.0 will offer the tools to do
> it readably and beautifully.

Please explain? If 9 out of 10 bare excepts can safely be replaced by
"except Exception", what's not beautiful about that?

> Also, as we learned with apply(), even if
> ignored, the deprecation machinery has a tremendous runtime cost.  None
> of this will make upgrading to Py2.5 an attractive option.

Not in this case; bare except: can be flagged by the parser so the
warning happens only once per compilation.
 
> There is a reason that over 120 bare except clauses remain in the
> standard library despite a number of attempts to get rid of them.

I betcha almost all of then can safely be replaced with "except Exception".

> Besides, I thought Guido was opposed to efforts to roam through
> mountains of code, making alterations in a non-holistic way.

This is trumped by the need to keep the standard library warning-free.

But how about the following compromise: make it a silent deprecation
in 2.5, and a full deprecation in 2.6.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)