
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. But in Pyrex, the distinction between Python and C is blurred. Currently, if you raise an exception in Pyrex using the implicit instantiation syntax, instantiation is also deferred, and I think this is a good thing. But if the implicit instantiation syntax goes away, this will no longer be possible while keeping the same syntax for the raise statement in Python and Pyrex. 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. 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. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+