[Twisted-Python] Re: Hanging test cases (Was: Evangelism notes...)

Bob Ippolito bob at redivi.com
Fri May 6 17:40:06 EDT 2005


On May 6, 2005, at 5:11 PM, David Bolen wrote:

> Jp Calderone <exarkun at divmod.com> writes:
>
>
>>   So as to be entirely clear, I'm going to limit this response to
>>   just one idea.  If more details are desired, I can post a followup
>>   later (as long as someone asks for one).  Anyway, for now, here's
>>   the meat of this post:
>>
>>
>>       Do
>>
>>       _____not_____
>>
>>       use
>>
>>       deferredResult
>>
>>       (or deferredError or wait)
>>
>>   As someone who pushed for their existence, I apologize.
>>
>
> Just to be clear, IMHO, I'd qualify this by saying something like in
> final production code or non-test code or something.  We make heavy
> use of these functions in our unit tests and they are invaluable ways
> to simplify the structure of such tests when each test is the only
> thing going on and there's no problem iterating the reactor beneath a
> blocking call.  We've also cheated and used them for pure startup code
> in GUI apps that are quick 'n dirty example interfaces into our main
> Twisted system, and again they can simplify such efforts.
>
> But I do agree they really have no place in final production code.

Sorry, but Jp is right.  They have no place in any code.  Their  
existence is a mistake and should be corrected ASAP.  They severely  
violate the reactor interface.

Something almost as easy would probably be waitDeferred and  
deferredGenerator in twisted.internet.defer (I don't know when they  
went in, but they're probably in 2.0).  See the waitDeferred's doc  
string for information.

The only way they could be "fixed" is if their implementation did  
something more like this:

def deferredResult(d):
     """untested because this code should not exist"""
     res = []
     def cb(result):
         res.append(result)
         reactor.stop()
     d.addBoth(cb)
     reactor.run()
     res = res.pop()
     if isinstance(res, Failure):
        failure.raiseException()
     return res

However, if their implementation did that, then the tests would  
probably break (because the tests are WRONG) or be a hell of a lot  
slower and even less reliable because there is no more timeout.

-bob





More information about the Twisted-Python mailing list