[Python-Dev] Style for raising exceptions (python-dev Summary for 2005-08-01 through 2005-08-15 [draft])
mcherm at mcherm.com
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
More information about the Python-Dev