Quoth Greg Ewing:
I'm worried about the proposed elimination of deferred instantiation of exceptions in Python code. The PEP asserts that this is an optimisation that should only be of interest in C code.
Yes -- and without argument! I quite liked writing that bit. Btw, just to be clear: in pure Python, deferred instantiation is already impossible; implicit instantiation is exactly equivalent to explicit. I admit I hadn't thought of Pyrex at all. I see that the trade-offs are different there, and deferring instantiation might well make lots of sense. [...]
It seems to me it's not necessary to eliminate implicit instantiation altogether, but only to remove the ambiguity between implicit and explicit instantiation. This could be done by mandating that
raise expr
*never* instantiates implicitly, whereas
raise classexpr, valueexpr
*always* instantiates implicitly, possibly also deferred.
In this plan, in order to raise, say, a TypeError with deferred instantiation and no arguments, you'd have to write raise TypeError, () right?
Specification of a traceback would be done with a new keyword, e.g.
raise expr [,expr] traceback tb
which I think is a good idea anyway, since it makes it a lot clearer what the currently-somewhat-obscure third argument actually is.
I like that. I would also like the traceback to be an attribute of the exception object (circular references be damned!), specified by optional keyword argument to Exception.__init__. This would require that people writing their own exception classes be sure to extend, not override, Exception.__init__. -- Steven Taschuk staschuk@telusplanet.net "[T]rue greatness is when your name is like ampere, watt, and fourier -- when it's spelled with a lower case letter." -- R.W. Hamming