Re: [Python-Dev] Bare except clauses in PEP 348
[PLEASE IGNORE PREVIOUS EMAIL... I HIT [Send] BY MISTAKE] Guido:
But how about the following compromise: make it a silent deprecation in 2.5, and a full deprecation in 2.6.
Reinhold Birkenfeld:
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.
Raymond:
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
participants (1)
-
Michael Chermside