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

Michael Hudson mwh at python.net
Mon Jun 9 13:49:28 CEST 2003


Armin Rigo <arigo at tunes.org> writes:

> 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...

But but but ... instantiating an Exception object involves calling a
callable, which unless you're careful will involve a call to
unpackiterable which depends on being able to raise IndexError ...

Actually, my change to decode_code_arguments may have made this
possible.  I'll check, but I'm sure there are other entertaining
infinite recursions lying in wait.

>> > 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.

Oh right.

I could explain how much I care about string exceptions, but with a
fixed width font, all characters are too wide.

Cheers,
M.

-- 
  The ability to quote is a serviceable substitute for wit.
                                                -- W. Somerset Maugham



More information about the Pypy-dev mailing list