[Python-Dev] Re: PEP-317

[Steven Taschuk]

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