Possibly Pythonic Tail Call Optimization (TCO/TRE)

Antoon Pardon antoon.pardon at rece.vub.ac.be
Fri Jul 17 12:48:21 CEST 2015

On 07/16/2015 06:43 PM, Chris Angelico wrote:
> On Fri, Jul 17, 2015 at 12:32 AM, Antoon Pardon
> <antoon.pardon at rece.vub.ac.be> wrote:
>> What is unclear about "as it is generally produced on stderr"? That you
>> can do a whole lot of stuff, doesn't mean that this whole lot of stuff is
>> part of what generally happens. When people on this list ask a person
>> to include the stacktrace with the description of the problem, they
>> don't mean something that includes the values of the variables.
> True. That said, though, it's not a justification for dropping stack
> frames; even in the form that's printed to stderr, there is immense
> value in them. It may be possible to explicitly drop frames that a
> programmer believes won't be useful, but a general and automated
> dropping of tail-call information will do more harm than good. The
> fact that some frameworks can show _even more_ helpful information out
> of a traceback only makes this stronger.

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. 

It seems a bit strange that with the immense value that is given to 
stack frames, that these wouldn't be available somehow.

Antoon Pardon

More information about the Python-list mailing list