Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Fri, 17 Jul 2015 14:54:14 +0200
From: Antoon Pardon <antoon.pardon@rece.vub.ac.be>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
References: <CAD+URuj-4e62-9hvpiLsrBP1M6kXRyZhZ6XyL01gWWnDoShvNg@mail.gmail.com> <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> <CAPTjJmrf9drR3Z7QUHSt+qCjY32EOm9aECR-gjiBRm3x-A+ang@mail.gmail.com>
In-Reply-To: <CAPTjJmrf9drR3Z7QUHSt+qCjY32EOm9aECR-gjiBRm3x-A+ang@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.647.1437137656.3674.python-list@python.org>
Lines: 39
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:94010

On 07/17/2015 01:49 PM, Chris Angelico wrote:
> On Fri, Jul 17, 2015 at 9:43 PM, Antoon Pardon
> <antoon.pardon@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