[Twisted-Python] Returning a Deferred as a result from another Deferred
rfugger at gmail.com
Tue Oct 9 01:59:49 EDT 2007
On 10/8/07, Jean-Paul Calderone <exarkun at divmod.com> wrote:
> On Fri, 5 Oct 2007 19:00:51 -0700, Ryan Fugger <rfugger at gmail.com> wrote:
> >On 10/5/07, Jonathan Lange <jml at mumak.net> wrote:
> >> On 10/6/07, Ryan Fugger <rfugger at 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()
In fact, that exact code raises the AssertionError in question. If
the intention is to allow this, then the assertion needs to be
> 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.
More information about the Twisted-Python