[pypy-dev] Re: [gmane.comp.python.pypy] deep breakage

[Armin Rigo]

Hello Michael,

On Mon, Jun 09, 2003 at 10:36:08AM +0100, Michael Hudson wrote:
> > We might either choose to mimic this behavior or clean it up a bit, e.g. by
> > always using internally a single object as the exception instance.
> 
> I couldn't get normalizing the exception at raise time (roughly what
> you mean here, right?) to work... there may be a reason other than
> performance that CPython does it this way.

Ah. Not sure exactly why. I am only aware of two ways CPython ever tries to
set exceptions: either by the 'raise' statement, which does the normalization
stuff immediately; or by one of the PyErr_SetXxx() calls, which as far as I am
aware is only ever used on built-in exception types (so no user code runs as a
result of normalizing these exceptions). The only reason I can see so far is
MemoryError, which (if we don't normalize it right away) can be raised without
memory allocation. However even this example is dubious, because we could have
a pre-built MemoryError instance in a corner just in case. But well, I'm not
completely aware of all the funny start-up inter-dependencies...

> > String exceptions are being deprecated, but still we could
> > reasonably emulate them, say by inventing a StringException
> > class. This would isolate the hacky parts around this specific class
> > (like setting sys.exc_type to something else than
> > current_exception.__class__ for this particular case).
> 
> I'm not sure I understand...

The point what just that if we replace the internal exc_type/exc_value pair
with a single exc_value pointer (which is the clean thing to do in my
opinion), then we cannot represent string exceptions any more and have to come
up with a new class whose instances can store both the string describing the
exception, and the associated value.


Armin