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

[Michael Chermside]

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