Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Chris Angelico]

On Fri, Jul 17, 2015 at 9:43 PM, Antoon Pardon
<antoon.pardon at rece.vub.ac.be> wrote:
> 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?

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. 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.

ChrisA