[Twisted-Python] Global reactor unit tests in the Twisted test suite

Phil Mayers p.mayers at imperial.ac.uk
Tue Nov 1 16:36:31 EDT 2011

On 11/01/2011 06:48 PM, Glyph wrote:

> Nevertheless, "real reactor as default argument" is not a huge
> improvement either, because it typically breaks one level out.  If
> you have 'a(reactor=defaultReactor)' and then 'b()' needs to call
> 'a', half the time 'b' will forget to supply a reactor argument and
> call 'a()' passing nothing, because that appears to be the suggested

Darn. I hadn't thought of that.

You could always walk back up the call stack looking for the 
implemenation of IReactorXXX that you want... what? Stop looking at me 
like that!

I kid of course... the right answer is to make everything a method on 
the reactor! No wait...

> So despite its imperfections, I don't have a solution better than
> "pass the reactor to everything" yet.  It seems to be better than the
> alternatives in almost every case.  The one place it's not better is
> when writing brief example scripts, but I suspect this is only the

Well, not only brief example scripts; brief actual scripts. One of the 
nice things about Twisted is that, with a bit of familiarity, you can 
knock up some really fast & powerful event-based network clients for 
ad-hoc jobs.

One example, we use a tiny script wrapping DeferredSemaphore and 
t.p.utils.getProcessOutput to parallelise SSH scanning, because 
ssh-keyscan is (ahem) poorly implemented.

Maybe I knock up more of these short 20-liners than is common? And 
typing "reactor, " a lot in them seems a bit, well... retrograde.

But you're right. Default "reactor=X" parameters will just get passed 
wrong, dammit...

> If you can think of a better solution that addresses all of these
> concerns simultaneously somehow, please share, I'd love to hear it
> :-).

Hmpf. I suspect you've covered most of the ground. If anything springs 
to mind I'll be sure to speak up!


More information about the Twisted-Python mailing list