On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> 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/) _______________________________________________ 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
