On Fri, 5 Oct 2007 19:00:51 -0700, Ryan Fugger wrote:

On 10/5/07, Jonathan Lange wrote:

...

On 10/6/07, Ryan Fugger 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