On 21 Jun, 11:57 pm, gl...@twistedmatrix.com wrote:
So I will save any further words I might write in this thread for
narrative documentation for cancellation :).
W
-glyph
___
Twisted-Python mailing list
Terry Jones te...@jon.es writes:
Based on JP's comment, I still think I'm missing something here.
The original subject of this thread? There was a question of what errorq
The problem that I was originally trying to address by getting 'cancel'
into deferreds is that the control flow you
Terry Jones te...@jon.es writes:
But, I also built some queuing things where I would have liked extra
information. For example, an app is processing jobs on behalf of a user,
[...]
Thinking about this for a little bit, it seems like there is quite a bit
more state to your jobs, that simply an
Hi Tom
Since most apis in twisted don't pass a canceller, the behavior is a2+a3.
Right. That was the intention (glyph's). It was expected that over time
more Twisted apis that create deferreds would add cancellers. As I
understand it, Kai Zhang is now adding cancellers to some apis returning
Hi again Tom
So, it seems to me that you want to represent your jobs as
more than simply a deferred. At the very least, you need to record what
the jobs is, so that it can be restarted later, if necessary.
Yes. The job class contained things like the function to call, its args,
timing
On 03:42 pm, te...@jon.es wrote:
Hi JP
Thanks for the summary. I agree (and agreed in my first post in this
thread) that the CancelledError should (has to) come all the way back.
I
missed that we were still talking about that.
Was there a conclusion on Glyph's suggestion of using subclasses
On 19 Jun, 07:49 pm, tom.pri...@ualberta.net wrote:
Well, it already raises `CancelledError`. Every deferred that doesn't
have explicitly handle cancelling already does:
from twisted.mail import smtp
from twisted.python import log
d = smtp.sendmail(host, options.sender, [], )
d.cancel()
Thank you for pointing this out. It seems like an important fact that
makes the rest of the discussion moot.
OK, maybe someone can explain the original Well, it already raises
`CancelledError`. Every deferred that doesn't have explicitly handle
cancelling already does: to me, because I didn't
Hi JP
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
By the way, I don't need any of this to make its way into Twisted. I can
still write my own class that does what I want (well, wanted). Below is a
2013 version of the CancelableDeferred. It's untested. The basic idea is
that if you get a regular deferred from somewhere, you can use the class
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
On Tue, Jun 18, 2013 at 8:37 AM, Itamar Turner-Trauring
ita...@futurefoundries.com wrote:
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
On Jun 18, 2013, at 8:42 AM, Christopher Armstrong ra...@twistedmatrix.com
wrote:
On Tue, Jun 18, 2013 at 8:37 AM, Itamar Turner-Trauring
ita...@futurefoundries.com wrote:
By way of background, Kai Zhang is one of our GSoC interns, working on adding
Deferred cancellation support to
On Tue, Jun 18, 2013 at 8:22 PM, Glyph gl...@twistedmatrix.com wrote:
I would say that if we want to percolate this information up to the
caller, there should be a ConnectingCancelled exception that is a subtype
of the previous exception type.
Doesn't that mean we'll have many subclasses
On Jun 18, 2013, at 12:03 PM, Laurens Van Houtven _...@lvh.io wrote:
On Tue, Jun 18, 2013 at 8:22 PM, Glyph gl...@twistedmatrix.com wrote:
I would say that if we want to percolate this information up to the caller,
there should be a ConnectingCancelled exception that is a subtype of the
On 06/18/2013 02:22 PM, Glyph wrote:
Making an API that previously documented raising (or failing)
exception types A, B, and C raise (or fail with) D is not necessarily
a compatible change. Making it raise (or fail with) A' (a subclass of
A) is, though.
The API for pop3client does *not*
16 matches
Mail list logo
