[Python-Dev] Bare except clauses in PEP 348
mcherm at mcherm.com
Thu Aug 25 19:55:30 CEST 2005
[PLEASE IGNORE PREVIOUS EMAIL... I HIT [Send] BY MISTAKE]
> But how about the following compromise: make it a silent deprecation
> in 2.5, and a full deprecation in 2.6.
> That said, I think that unless it is a new feature (like with statements)
> transitions to Python 3.0 shouldn't be enforced in the 2.x series. With 3.0,
> everyone expects a clear cut and a compatibility breach.
> I'd love to compromise but it's your language. If you're going to
> deprecate, just do it. Pulling the band-aid off slowly doesn't lessen
> the total pain.
There are actually THREE possible levels of deprecation available. In order
of severity, they are:
1. Modifying the documentation to advise people to avoid this feature.
No one gets alerted.
2. Using a PendingDeprecationWarning so people who explicitly request
it can have the compiler alert them when they use it.
3. Using a DeprecationWarning so people using it are alerted unless they
explicitly request NOT to be alerted.
I think 3 is unwarrented in this case. For reasons I explained in a previous
posting, I would be in favor of 2 if we can *also* have a
PendingDeprecationWarning for use of string exceptions and arbitrary-object
exceptions (those not derived from BaseException). I am in favor of 3 in
any case. Of course, that's just one person's opinion...
Raymond also raised this excellent point:
> 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. [...]
> 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.
That seems like a fair criticism to me. As we've already noted, it is
impossible to replace ALL uses of bare "except:" in 2.5 (particularly
the use in code.py that Guido referred to). But we ought to make an
extra effort to remove unnecessary uses of bare "except:" from the
standard library if we intend to deprecate it.
-- Michael Chermisde
More information about the Python-Dev