Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
Date: Fri, 17 Jul 2015 16:27:49 -0400
References: <CAD+URuj-4e62-9hvpiLsrBP1M6kXRyZhZ6XyL01gWWnDoShvNg@mail.gmail.com> <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
In-Reply-To: <55A8EA7D.2040005@rece.vub.ac.be>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.658.1437164908.3674.python-list@python.org>
Lines: 44
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:94030

On 7/17/2015 7:43 AM, Antoon Pardon wrote:
> On 07/17/2015 01:05 PM, Chris Angelico wrote:

>> 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.

No more than any other object sitting around inactive. Calling a 
generator function like gen above returns a generator with the generator 
function, in a suspended inactive state, attached as an attribute.  When 
the generator.__next__ function is called, it activates its instance of 
the generator function, which suspends itself again after yielding 
something.  At the point of the exception above, the generator next 
function has returned.  There could be multiple generators with 
suspended generator functions sitting around.  For instance:

def f():
     for tup in zip(gf0, gf1, gf2, gf3, gf4, gf5):
         a = tup[6]  # whoops, IndexError
         <unreachable code meant to do something>

-- 
Terry Jan Reedy