> > 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.
That's good news. It mitigates runtime cost completely.
> > 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".
Because the tree is not being re-arranged until 3.0, those cases should
also introduce a preceding:
except (KeyboardInterrupt, SystemExit):
raise
Anywhere that doesn't apply will need:
except BaseException:
. . .
and also some corresponding backwards compatibility code to work with
older pythons.
If any are expected to work with user or third-party modules, then they
cannot safely ignore string exceptions and exceptions not derived from
Exception.
Each of those changes needs to be accompanied by test cases so that all
code paths get exercised.
After the change, we should run Zope, Twisted, Gadfly, etc to make sure
no major application got broken. Long running apps should verify that
their recover and restart routines haven't been compromised. This is
doubly true if the invariant for a bare except was being relied upon as
a security measure (this may or may not be a real issue).
> But how about the following compromise: make it a silent deprecation
> in 2.5, and a full deprecation in 2.6.
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.
My preference is of course, to leave 2.x alone and make this part of the
attraction to 3.0. Remember, none of the code changes buys us anything
in 2.x. It is an exercise without payoff.
My even stronger preference is to leave bare excepts in for Py3.0. That
buys us a happy world where code old code continues to work and new code
can be written that functions as intended on all pythons new and old.
I'm no fan of bare exceptions, but I'm not inclined to shoot myself in
the foot to be rid of them. I wish Fredrik would chime in. He would
have something pithy, angry, and incisive to say about this.
Raymond
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
