<div class="gmail_quote">On Tue, Nov 1, 2011 at 5:29 PM, Anton Gyllenberg <span dir="ltr">&lt;<a href="mailto:anton@iki.fi">anton@iki.fi</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Nov 1, 2011 at 20:48, Glyph &lt;<a href="mailto:glyph@twistedmatrix.com">glyph@twistedmatrix.com</a>&gt; wrote:<br>
&gt; On Nov 1, 2011, at 12:14 PM, Phil Mayers wrote:<br>
</div><div class="im">&gt;&gt; I find the &quot;pass reactor as 1st argument to everything&quot; API pattern<br>
&gt;&gt; messy. I&#39;m sure there&#39;s a good reason. What is it?<br>
&gt;<br>
&gt; This pattern is a solution to the problem, but I agree that it is possibly not the optimal solution.  It sort of points in a direction where every possible module that might be imported becomes an argument to your function.  After all, there are plenty of other modules which have to be mocked for testing, why not just make everyone&#39;s __init__ method take sys.modules as an argument too, and never import anything?  In more complex systems this can definitely turn into a bit of a mess.<br>

<br>
</div>I&#39;ve often wondered whether there is a *real* use of the reactor<br>
argument other than unit testing. I haven&#39;t had other uses for it, and<br>
haven&#39;t seen (or perhaps not understood) real application code making<br>
use of it. Now, I&#39;ve sometimes made an argument for unit testing,<br>
other than the obvious quality assurance, that unit tested code will<br>
be more reusable and have better interfaces as it already is used for<br>
at least two things: the real application and the unit test. However,<br>
if accommodating unit testing requires sacrificing the natural<br>
interface, then that kind of takes the edge off that argument.<br>
<br>
Thanks to everybody for the discussion and input. Very informative!<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>Here&#39;s the thing: not only does removing the global reactor make *our* unit tests a lot nicer, it makes the unit tests of our users much easier to write, since they will want to use our APIs in their unit tests in a way that doesn&#39;t require ugly global hacking. I don&#39;t know how many times I have raged at some crappy library whose code is incompatible with consumer unit testing. Having testable interfaces is a really valuable feature we can provide to our users.</div>
<div><br></div><div>-- </div></div>Christopher Armstrong<br><a href="http://radix.twistedmatrix.com/">http://radix.twistedmatrix.com/</a><br><a href="http://planet-if.com/">http://planet-if.com/</a><br><br><br>