<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:13px">Thank you for pointing this out.  It seems like an important fact that makes the rest of the discussion moot.</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">OK, maybe someone can explain the original "</span><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">Well, it already raises `CancelledError`. Every deferred that doesn't </span><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">have explicitly handle cancelling already does:" to me, because I didn't get it at all!</span></div>
<div style><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">Terry</span></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Jun 20, 2013 at 8:34 PM,  <span dir="ltr"><<a href="mailto:exarkun@twistedmatrix.com" target="_blank">exarkun@twistedmatrix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 19 Jun, 07:49 pm, <a href="mailto:tom.prince@ualberta.net" target="_blank">tom.prince@ualberta.net</a> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Well, it already raises `CancelledError`. Every deferred that doesn't<br>
have explicitly handle cancelling already does:<br>
<br>
from twisted.mail import smtp<br>
from twisted.python import log<br>
<br>
d = smtp.sendmail("host", "options.sender", [], "")<br>
d.cancel()<br>
d.addErrback(log.err, "Here be CancelledError")<br>
</blockquote>
<br></div>
Thank you for pointing this out.  It seems like an important fact that makes the rest of the discussion moot.<br>
<br>
By making `Deferred.cancel` work on any Deferred by triggering a `CancelledError`, we have already decided on the failure behavior for all existing Deferred-returning APIs.  Changing that at this point doesn't seem like a very good idea.<br>

<br>
I think I'd also like to challenge the idea that Glyph put forwards earlier in the thread that this extra information is *necessarily* important to the application.<br>
<br>
So far, I haven't written any applications that care about the exact stage at which the operation is cancelled.  All they care about is that the operation *is* cancelled (ie, resources are cleaned up) and that the Deferred fires soon.  There's lots of utility in just this level of functionality which requires no extra information about the internal progress of the operation.<br>

<br>
This is not to say that I believe there is no application that might want this information, but maybe someone can propose some concrete use cases for this information and design can follow from that.  So far I don't think any practical justification to do anything other than `CancelledError` has been presented.<br>

<br>
Jean-Paul<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Twisted-Python mailing list<br>
<a href="mailto:Twisted-Python@twistedmatrix.com" target="_blank">Twisted-Python@twistedmatrix.<u></u>com</a><br>
<a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python" target="_blank">http://twistedmatrix.com/cgi-<u></u>bin/mailman/listinfo/twisted-<u></u>python</a><br>
</div></div></blockquote></div><br></div>