[Python-Dev] Style for raising exceptions (python-dev Summary for 2005年08月01日 through 2005年08月15日 [draft])

Fri Aug 26 15:15:17 CEST 2005

Marc-Andre Lemburg writes:
> This is from a comment in ceval.c:
>> 	/* We support the following forms of raise:
> 	 raise <class>, <classinstance>
> 	 raise <class>, <argument tuple>
> 	 raise <class>, None
> 	 raise <class>, <argument>
> 	 raise <classinstance>, None
> 	 raise <string>, <object>
> 	 raise <string>, None
>> 	 An omitted second argument is the same as None.
>> 	 In addition, raise <tuple>, <anything> is the same as
> 	 raising the tuple's first item (and it better have one!);
> 	 this rule is applied recursively.
>> 	 Finally, an optional third argument can be supplied, which
> 	 gives the traceback to be substituted (useful when
> 	 re-raising an exception after examining it). */
>> That's quite a list of combinations that will all break
> in Python 3.0 if we only allow "raise <classinstance>".

Oh my GOD! Are you saying that in order to correctly read Python code
that a programmer must know all of THAT! I would be entirely
unsurprised to learn that NO ONE on this list... in fact, no one
in the whole world could have reproduced that specification from
memory accurately. I have never seen a more convincing argument for
why we should allow only limited forms in Python 3.0.
And next time that I find myself in need of an obfuscated python
entry, I've got a great trick up my sleeve.
-- Michael Chermside