This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Mark.Shannon
Recipients Jim.Jewett, Mark.Shannon, amaury.forgeotdarc, benjamin.peterson, jcea, ncoghlan, ron_adam
Date 2012-03-07.08:23:44
SpamBayes Score 0.0014566373
Marked as misclassified No
Message-id <4F571B0F.5020309@hotpy.org>
In-reply-to <1331097018.28.0.356824358453.issue13897@psf.upfronthosting.co.za>
Content
Jim Jewett wrote:
 > http://bugs.python.org/review/13897/diff/4186/14521
 > File Python/sysmodule.c (right):
 >
 > http://bugs.python.org/review/13897/diff/4186/14521#newcode211
 > Python/sysmodule.c:211: while ((exc_info->exc_type == NULL ||
 > exc_info->exc_type == Py_None) &&
 > This while loop is new, but it isn't clear how it is related to
 > encapsulating the exception state.  Is this fixing an unrelated bug, or
 > is it from generators, or ..?
 >
 > http://bugs.python.org/review/13897/show

Running generators form a stack, much like frames.
Calling a generator with next or send, pushes it onto the stack,
yielding pops it.

Now consider, if you will, the threadstate object as a sort of
non-yielding (it cannot be popped) generator which forms the base
of this stack.

In this patch, rather than swapping the exception state between 
generator-owned frame and threadstate whenever entering or leaving a 
generator, each generator (and the threadstate) has its own exception state.

It order to find the topmost exception state, sys.exc_info searches the 
stack of generators until it finds one.
In practice the generator stack will be very shallow, only 1 or 2 deep,
as it is rare to have generators calling other generators
(although this will become a bit more common with PEP 380).
History
Date User Action Args
2012-03-07 08:23:45Mark.Shannonsetrecipients: + Mark.Shannon, jcea, amaury.forgeotdarc, ncoghlan, ron_adam, benjamin.peterson, Jim.Jewett
2012-03-07 08:23:44Mark.Shannonlinkissue13897 messages
2012-03-07 08:23:44Mark.Shannoncreate