On 07/17/2015 01:49 PM, Chris Angelico wrote: > On Fri, Jul 17, 2015 at 9:43 PM, Antoon Pardon > <antoon.par...@rece.vub.ac.be> wrote: > > >> Sure, but in this case, the generator is still active. The Runtime >> would be able to jump to and somehow activates it's stack record >> for the next value. So why would we expect it to be impossible to >> include this trace back record in a stack trace? > Python could also give you stack traces for any other threads that are > concurrently running, on the off-chance that one of them affected it. > But the only influence the generator has on the loop is to yield a > value or signal termination; if an exception is thrown in the loop > itself, the local name 'stuff' should have all the information about > that cause.
But the local name 'stuff' may only have the information for the immediate cause. The underlying cause may be available in the generator. Suppose you have a generator that should only generate positive numbers that you use to divide some other number by. Your loop crashes because of a DivideByZeroError Sure the local name shows the dividor to be zero, but you have no information on why your generator produced a zero, but there may be a clue in the trace back record of the generator. > Python isn't a mind-reader, no matter how much it may look > like one, and it can't know that this function's return value should > be shown as part of a completely different function's stack trace. It is not a matter of mindreading. And it is not a completely different functions stack trace. It is the trace back record of a generator that is used by the process/thread that crashed. And AFAIK an active generator belongs to one specific thread. You can't have it yield a value to a different thread and you can't send it a value from an other thread. So I really see no reason to exclude the trace back records of active generators from a stack trace of a crashed thread. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
