[Python-Dev] Bare except clauses in PEP 348

Raymond Hettinger raymond.hettinger at verizon.net
Thu Aug 25 17:58:48 CEST 2005


> Deprecation means your code will still work I hope every book that
> documents "except:" also adds "but don't use this except under very
> special circumstances".
> 
> I think you're overreacting (again), Raymond. 3.0 will be much more
> successful if we can introduce many of its features into 2.x. Many of
> those features are in fact improvements of the language even if they
> break old code. We're trying to balance between breaking old code and
> introducing new features; deprecation is the accepted way to do this.

IMO, the proponents of 2.x deprecation are underreacting.  Deprecation
has a cost -- there needs to be a corresponding payoff.  Deprecation is
warranted if the substitute code would still run on future Pythons
(Michael explained the issues here).  Deprecation is only warranted if
the interim substitute works -- AFAICT, there is no other way to broadly
catch exceptions not derived from Exception.  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.  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.

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.  It
won't be trivial to properly evaluate whether each should be Exception
or BaseException; to catch string exceptions; to write the test cases;
to follow other PEPs requiring compatibility with older Pythons; or to
do this in a way that it won't have to be done again for Py3.0.  If the
proponents don't have time to fix the standard library, how can they in
good conscience mandate change for the rest of the world.

Besides, I thought Guido was opposed to efforts to roam through
mountains of code, making alterations in a non-holistic way.  With a
change this complex, the odds of introducing errors are very high.

Fredrik, please speak up.  Someone should represent the users here.  I'm
reached my limit on how much time I can devote to thinking out the
implications of these proposals.  Someone else needs to "overreact". 



More information about the Python-Dev mailing list