Re: [Twisted-Python] Returning a Deferred as a result from another Deferred
On Fri, 5 Oct 2007 19:00:51 -0700, Ryan Fugger <rfugger@gmail.com> wrote:
On 10/5/07, Jonathan Lange <jml@mumak.net> wrote:
On 10/6/07, Ryan Fugger <rfugger@gmail.com> wrote:
Returning a Deferred as a result from another Deferred seems to be disallowed by an assertion at the start of the callback chain. Why is this? Right now I have worked around this limitation by wrapping my Deferred in a list and then unwrapping it in the callback.
No it's not. I can guarantee this.
What's the content of the AssertionError that you are getting?
No content in the error. Line 238 of twisted/internet/defer.py (first line in Deferred.callback) is:
assert not isinstance(result, Deferred)
That's pretty explicit in disallowing Deferreds... I'm working with the version 2.5 release.
You've misread the code. Jonathan is correct. The rest of this thread seems to go off on some tangent about threads which may or may not be relevant to whatever problem you're trying to solve. What led you to be reading this code in the first place? Glyph did make a good point, though. You shouldn't ever have a Deferred in a thread other than the reactor thread. You shouldn't make them, you shouldn't add callbacks to them, you shouldn't call them back. It might be legitimate to get one from the reactor thread, hold it for a while, then send it back to the reactor thread, but I can't think of a case where this would really be very useful. Jean-Paul
Ryan
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On 10/8/07, Jean-Paul Calderone <exarkun@divmod.com> wrote:
On Fri, 5 Oct 2007 19:00:51 -0700, Ryan Fugger <rfugger@gmail.com> wrote:
On 10/5/07, Jonathan Lange <jml@mumak.net> wrote:
On 10/6/07, Ryan Fugger <rfugger@gmail.com> wrote:
Returning a Deferred as a result from another Deferred seems to be disallowed by an assertion at the start of the callback chain. Why is this? Right now I have worked around this limitation by wrapping my Deferred in a list and then unwrapping it in the callback.
No it's not. I can guarantee this.
What's the content of the AssertionError that you are getting?
No content in the error. Line 238 of twisted/internet/defer.py (first line in Deferred.callback) is:
assert not isinstance(result, Deferred)
That's pretty explicit in disallowing Deferreds... I'm working with the version 2.5 release.
You've misread the code. Jonathan is correct.
What is that assertion guarding against then? Seems to me like it is explicitly preventing you from doing this: d1 = Deferred() d2 = Deferred() d1.callback(d2) In fact, that exact code raises the AssertionError in question. If the intention is to allow this, then the assertion needs to be removed.
The rest of this thread seems to go off on some tangent about threads which may or may not be relevant to whatever problem you're trying to solve. What led you to be reading this code in the first place?
Glyph did make a good point, though. You shouldn't ever have a Deferred in a thread other than the reactor thread. You shouldn't make them, you shouldn't add callbacks to them, you shouldn't call them back. It might be legitimate to get one from the reactor thread, hold it for a while, then send it back to the reactor thread, but I can't think of a case where this would really be very useful.
Yes, and thanks for that. I was creating a Deferred and adding a callback in a thread, so in fixing that, the assertion above no longer comes into play. Ryan
On Mon, 8 Oct 2007 22:59:49 -0700, Ryan Fugger <rfugger@gmail.com> wrote:
On 10/8/07, Jean-Paul Calderone <exarkun@divmod.com> wrote:
On Fri, 5 Oct 2007 19:00:51 -0700, Ryan Fugger <rfugger@gmail.com> wrote:
On 10/5/07, Jonathan Lange <jml@mumak.net> wrote:
On 10/6/07, Ryan Fugger <rfugger@gmail.com> wrote:
Returning a Deferred as a result from another Deferred seems to be disallowed by an assertion at the start of the callback chain.
You've misread the code. Jonathan is correct.
What is that assertion guarding against then? Seems to me like it is explicitly preventing you from doing this:
d1 = Deferred() d2 = Deferred() d1.callback(d2)
In fact, that exact code raises the AssertionError in question. If the intention is to allow this, then the assertion needs to be removed.
Here's what it sounds like "returning a Deferred as a result from another Deferred" describes: def f(result): return Deferred() d = Deferred() d.addCallback(f) d.callback(None) This is a useful and very common thing to do. I see this isn't what you were attempting to describe now, though. Jean-Paul
participants (2)
-
Jean-Paul Calderone -
Ryan Fugger