Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Antoon Pardon]

On 07/17/2015 01:05 PM, Chris Angelico wrote:
> On Fri, Jul 17, 2015 at 8:48 PM, Antoon Pardon
> <antoon.pardon at rece.vub.ac.be> wrote:
>> Just wondering, are traceback records of generators available? They are
>> if an exception is raised in the generator itself, but what if an exception
>> is raised in the loop that is driven by a generator. They don't appear in
>> the standard stack trace.
> Not sure what you mean here. Something like this?
>
> def gen():
>     yield stuff
>     yield more stuff
>
> for stuff in gen():
>     bomb with exception
>
> The error didn't happen in the generator, so I wouldn't expect to see
> it in the traceback.

Yes something like that. And I wouldn't expect it either but if it
is not present, is it because nobody thought about it or because it
is a bad idea or an idea difficult to implement?

> There's still room for the cause of an error to
> not be in the traceback; imagine, for instance, a function that
> populates a concrete list, and then you iterate over the list. If that
> function sticks a None into the list and the subsequent processing is
> expecting all strings, that's going to bomb, but then you have to
> figure out where the None came from. If the traceback could include
> that, it'd be great, but some things aren't possible.

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?

>  Doesn't mean
> we're happy to sacrifice other functionality.

Indeed, this is an independend problem. Whatever the answer here doesn't
need to affect how one feels about losing trace back record because of
TCO.