Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <55A8EA7D.2040005@rece.vub.ac.be>
References: <CAD+URuj-4e62-9hvpiLsrBP1M6kXRyZhZ6XyL01gWWnDoShvNg@mail.gmail.com> <mailman.481.1436851550.3674.python-list@python.org> <87bnff1eks.fsf@jester.gateway.sonic.net> <mailman.499.1436874241.3674.python-list@python.org> <87d1zunctp.fsf@elektro.pacujo.net> <mailman.503.1436878550.3674.python-list@python.org> <87k2u2eu67.fsf@elektro.pacujo.net> <CAPTjJmqtTRHpNZHByn1pKNSfbsG6X--s2d_G0FopKxDugqpjdA@mail.gmail.com> <55A51662.4090007@rece.vub.ac.be> <mo4a7g$mkg$1@ger.gmane.org> <mailman.531.1436951405.3674.python-list@python.org> <d0o60cF8ubiU1@mid.individual.net> <55A75DE0.1070101@rece.vub.ac.be> <CAPTjJmoWqhZ_P890qug3Zf=VjJOBmO5kOSaX08PDF3FdNyLFNA@mail.gmail.com> <55A7B80B.6090905@rece.vub.ac.be> <CAPTjJmp3mupnenUYYNmvJpNr27zx_CdHQ9m6wkEFi-Lz+Evw9A@mail.gmail.com> <55A7C094.7060604@rece.vub.ac.be> <CAPTjJmozknJAqPvE1W1JZ66u72hNc_R5j5=wo+2JJK30Z5oc6w@mail.gmail.com> <55A8DD75.5000403@rece.vub.ac.be> <CAPTjJmrK=A7=4MYLbFdRBGjkr1qm442b_Ci-SQVmf6_2z97KtA@mail.gmail.com> <55A8EA7D.2040005@rece.vub.ac.be>
Date: Fri, 17 Jul 2015 21:49:57 +1000
Subject: Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.644.1437133800.3674.python-list@python.org>
Lines: 48
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:94007

On Fri, Jul 17, 2015 at 9:43 PM, Antoon Pardon
<antoon.pardon@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@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