<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>t+1 - Latest Comments in Wacky idea for python coroutines</title><link>http://tplus1.disqus.com/</link><description></description><atom:link href="https://tplus1.disqus.com/wacky_idea_for_python_coroutines_34/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Sat, 21 Jun 2008 09:48:42 -0000</lastBuildDate><item><title>Re: Wacky idea for python coroutines</title><link>http://blog.tplus1.com/blog/2008/06/13/wacky-idea-for-python-coroutines/#comment-721547</link><description>&lt;p&gt;Hi Calvin -- thanks for the comment!  After the callback fires, how can I go back into the code that originally raised the exception?  As far as I understand, that frame is inacessible.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Matt Wilson</dc:creator><pubDate>Sat, 21 Jun 2008 09:48:42 -0000</pubDate></item><item><title>Re: Wacky idea for python coroutines</title><link>http://blog.tplus1.com/blog/2008/06/13/wacky-idea-for-python-coroutines/#comment-720394</link><description>&lt;p&gt;I've thought about this but came to the conclusion that this begs a distinction between error handling and error repair and repair we can simply handle with proper callbacks.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Calvin</dc:creator><pubDate>Sat, 21 Jun 2008 00:32:19 -0000</pubDate></item><item><title>Re: Wacky idea for python coroutines</title><link>http://blog.tplus1.com/blog/2008/06/13/wacky-idea-for-python-coroutines/#comment-680427</link><description>&lt;p&gt;Florian, thanks for the extra detail.  I think I need to study co-routines in stackless, pypy, and greenlets before I will really understand your point.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Matt Wilson</dc:creator><pubDate>Sun, 15 Jun 2008 16:37:24 -0000</pubDate></item><item><title>Re: Wacky idea for python coroutines</title><link>http://blog.tplus1.com/blog/2008/06/13/wacky-idea-for-python-coroutines/#comment-680375</link><description>&lt;p&gt;I mean to say generators with yield/send are not full co-routines. Full co-routines can switch to another thread of execution from anywhere within the call stack and return there later. If you want to do the same with generators, you need to start treating every "call" as an iteration.&lt;br&gt;Hence generators are very pointless to use as co-routines, and greenlets which are actually co-routines are much better at that capacity.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Florian</dc:creator><pubDate>Sun, 15 Jun 2008 16:17:22 -0000</pubDate></item><item><title>Re: Wacky idea for python coroutines</title><link>http://blog.tplus1.com/blog/2008/06/13/wacky-idea-for-python-coroutines/#comment-679924</link><description>&lt;p&gt;Florian -- I don't think I follow you.  What do you mean by yielding across call stacks?  How is that different than regular yield and send?&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Matt Wilson</dc:creator><pubDate>Sun, 15 Jun 2008 13:56:18 -0000</pubDate></item><item><title>Re: Wacky idea for python coroutines</title><link>http://blog.tplus1.com/blog/2008/06/13/wacky-idea-for-python-coroutines/#comment-679548</link><description>&lt;p&gt;Without the ability to yield across call stacks, generators as co-routines are useless. I'd suggest using co-routines as co-routines, in this case, which are implemented by stackless, pypy and the greenlet module.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Florian</dc:creator><pubDate>Sun, 15 Jun 2008 12:01:59 -0000</pubDate></item></channel></rss>