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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4