There's an exception for "a deferred has been cancelled".  Cancelling a deferred fires that down its errback chain just like any exception. Since @inlineCallbacks works on top of deferreds, it magically works:<br>

<br><br>>>> from twisted.internet import defer<br>>>> d = defer.Deferred()<br>>>> @defer.inlineCallbacks<br>... def f():<br>...     yield d<br>... <br>>>> r = f()<br>>>> r<br>
<Deferred at 0x1019df950><br>
>>> d.cancel()<br>>>> r<br><Deferred at 0x1019df950 current result: <twisted.python.failure.Failure <class 'twisted.internet.defer.CancelledError'>>><br><br><div class="gmail_quote">

On Fri, Oct 26, 2012 at 5:25 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On Fri, Oct 26, 2012 at 7:12 AM, Itamar Turner-Trauring<br>
<<a href="mailto:itamar@futurefoundries.com">itamar@futurefoundries.com</a>> wrote:<br>
><br>
><br>
> On Wed, Oct 24, 2012 at 7:43 PM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
>><br>
>><br>
>> > I don't know, I hope someone with an expertise in Twisted can tell us.<br>
>> ><br>
>> > But I would imagine that they don't have this particular problem, as it<br>
>> > should be related only to coroutines and schedulers that run them.  I.e.<br>
>> > it's a problem when you run some code and may interrupt it.  And you<br>
>> > can't<br>
>> > interrupt a plain python code that uses callbacks without yields and<br>
>> > greenlets.<br>
>><br>
>> Well, but in the Twisted world, if a cleanup callback requires more<br>
>> blocking calls, it has to spawn more deferred callbacks. So I think<br>
>> they *do* have the problem, unless they don't have a way at all to<br>
>> constrain the total running time of an action involving cascading<br>
>> callbacks. Also, they have inlineCallbacks which does use yield.<br>
><br>
><br>
> Deferreds don't do anything to prevent blocking. They're just a nice<br>
> abstraction for callbacks. And yes, if you call 1000 functions that do lots<br>
> of CPU in a row, that will keep other stuff from happening.<br>
><br>
> However, consider how a timeout works: the event loop notices enough time<br>
> has passed, and so calls some code that tells the Deferred to cancel its<br>
> operation. So you're *not* adding the cancellation operations to the stack<br>
> of the original operation, you're starting from the event loop. And so<br>
> timeouts are just normal event loop world, where you need to be careful not<br>
> to do to much CPU-intensive processing in any given call, and you can't call<br>
> blocking system calls (except using a thread).<br>
><br>
> Of course, you can't timeout a function that's just looping using CPU, or a<br>
> blocking system call, and so code needs to be structured to deal with this,<br>
> but that's a different issue.<br>
<br>
</div></div>So, basically, it's just "after T seconds you get this second callback<br>
and it's up to you to deal with it"? I guess the timeout callback can<br>
inspect the state of the operation, and cancel any pending operations?<br>
<br>
Do you have a way to translate timeouts into exceptions in<br>
inlineCallbacks? If so, how is that working out?<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>cheers<div>lvh</div><br>