<div dir="ltr">On Tue, Jun 18, 2013 at 8:37 AM, Itamar Turner-Trauring <span dir="ltr"><<a href="mailto:itamar@futurefoundries.com" target="_blank">itamar@futurefoundries.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">By way of background, Kai Zhang is one of our GSoC interns, working on adding Deferred cancellation support to Twisted. I believe the specific module he is working on is the POP3 client, but it's a general question - should we try to keep CancelledError percolating all the way to the top of callback chain when possible? My first thought is "yes" since that's a more informative reason, but maybe someone else has a counter-argument</div>
</blockquote><div><br></div><div style>I definitely think the error should explain that cancellation occurred; I can also imagine cases where you'd want to know the specifics of how that cancellation occurred, or how far some operation got before the cancellation was executed (especially if we're talking about mutating operations). ConnectionDone definitely doesn't sound good.</div>
</div><div><br></div>-- <br>Christopher Armstrong<br><a href="http://radix.twistedmatrix.com/">http://radix.twistedmatrix.com/</a><br><a href="http://planet-if.com/">http://planet-if.com/</a><br><br>
</div></div>