Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Antoon Pardon]

On 07/17/2015 01:49 PM, Chris Angelico wrote:
> On Fri, Jul 17, 2015 at 9:43 PM, Antoon Pardon
> <antoon.pardon at 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