See http://mail.python.org/pipermail/python-3000/2008-March/012830.html
: the exception state can survive across thread switches if the
enclosing frame is not destroyed immediately.

And this is a patch, together with a test.

Thanks for the patch. This isn't specific to threads at all, so the test
doesn't need to spawn a thread, just raise an exception from a nested
function with a parameter, catch it, delete the object the parameter
referred to, and then check that the object has been destroyed.

I don't know the exception handling code very well, so I'd like someone
more familiar with it to check that the patch is correct and efficient.
Collin, would you do the honors?

You are right, threads aren't needed. So, attaching an updated patch.

Knocking the priority down to critical for the next alpha release.  This
can be readdressed once the release is made.

A new patch with just an updated comment in ceval.c.

Looks good to me. Antoine, do you have commit privileges?

No, I don't.

Here is a last patch fixing without lines longer than 78 chars.

r62847

This bug should be reopened, the patch does not fix it when the except
clause does not assign the exception to a local variable (that is,
"except KeyError" rather than "except KeyError as e").
Another can of worms also appeared in #2833...

This is a complementary patch that should fix the remaining cases
(funnily doctest was relying on the old behaviour).
Unfortunately #2833 still remains, and would probably need some
discussion on the ML for proper resolution.

For time being, should r62847 be reverted?

I don't think so. As Amaury pointed in #2833, the original re-raising
behaviour which got changed by fixing the present bug was rather broken
in its own way.
Anyway, I think the question better be asked on the ML because any
solution for the re-raising behaviour will require some significant
trickery in the compiler and the eval loop.

Patch removed, there are still some unsolved cases :-)

Here is a hopefully complete patch using the same approach as before.

However I'm now convinced that another approach would be better in order
to solve both this bug and the various re-raising issues. It would
involve replacing most of the set_exc_info() / reset_exc_info()
mechanism in ceval.c with something different, probably based on
saving/restoring exception state values onto/from the frame stack.
Problem is, I'm not sure I'll have time for it very soon.

A clean solution is now proposed in #3021.

Solved by r64121.