Guido van Rossum <[EMAIL PROTECTED]> added the comment: I finally figured this out. The try/except statement is a complete red herring; the problem is in the raise statement. The behavior is the same in 2.4, 2.5 and 2.6, even though Exception is a classic class in 2.4 and a new-style class in 2.5 and 2.6.
The rules are relatively straightforward, and explain all observations, once you realize that attempting to raise something that is not allowed raises a TypeError: - you can raise strings (except in 2.6 -- see footnote) - you can raise any classic class - you can raise any class that derives from [Base]Exception (That last rule is subtle, due to standard exceptions changing from classic to new-style in 2.5.) I do not believe that there is anything wrong in this set of rules, and would object to a change that would allow raising any new-style class in 2.6, since this would be a temporary relaxation of the rules, whereas in 3.0 we will be significantly *tightening* the rules! PEP 352 states that in Python 2.7 we will deprecate raising exceptions that don't derive from BaseException; in 2.8 we will deprecate catching those; and 2.9 we may deprecate __getitem__ on exceptions. This was written before 3.0 was really planned; IMO we should have "-3" warnings for all these things in 2.6. This implies that "except object:" will get a -3 warning -- but not a deprecation warning. I do recommend that these rules be documented more clearly. (Footnote: if I read PEP 352 carefully, I don't believe raising strings was supposed to be disallowed before 3.0. I'm not sure it's worth reverting this though.) ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2291> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
