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 _______________________________________________ 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
