<div class="gmail_quote">On Fri, Dec 7, 2012 at 8:01 PM, Damian Johnson <span dir="ltr"><<a href="mailto:atagar@torproject.org" target="_blank">atagar@torproject.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> The quoted key/value mapping is more readable, now.  Good work.  Why not look for quoted positional args before non-quoted positional args?  Why not do just like kwarg handling?<br> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

MY_EVENT "arg1 arg2"<br>
<br>
... where the spec says we really *do* have two non-quoted positional<br>
arguments. That said, if we ever saw such a thing I'd probably<br>
conclude that tor was *trying* to confuse us. :P<br>
<br>
Patch welcome.<br></blockquote><div><br>I must not be reasoning about Event._parse_standard_attr() correctly.  I think it is already looking for _QUOTED positional args, but is working at it backwards from _KEYWORD_ARGS parsing.<br>
<br>Well, I already wanted to write unit tests for Event.  So, I'll try exercising the class and see what I can see.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> Why restrict SignalEvents to expected_signals when control-spec.txt allows more?  This may mean changes later to add support for things the protocol already claims to support.<br>
<br>
</div>It's not being restricted. The expected_signals is only used so that<br>
we log if we get something else. It doesn't prevent us from having<br>
other values - I'd just like to know if we get them since the pydocs<br>
and spec would then need to be tweaked.<br></blockquote><div><br>While preparing to argue further, I see the mistake I made: SIGNAL command versus SIGNAL event.  I was reading the wrong part of the spec.  Please disregard.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> I set up coverage.py for another project and I wondered if it would work with Stem. <br></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
</div>Sweet! Mind sending me a link to the coverage tool? I'd like to see<br>
which modules are lacking coverage.<br></blockquote><div><br><a href="http://nedbatchelder.com/code/coverage/">http://nedbatchelder.com/code/coverage/</a><br><a href="http://pypi.python.org/pypi/coverage">http://pypi.python.org/pypi/coverage</a><br>
<br>I've used this on three projects (not counting Stem) and it helps check that written tests are reaching all the dark crevices of one's code.  If you have questions, I'm happy to help. Once installed, do:<br>
<br>1) coverage run --parallel-mode --branch --omit="test*" ./run_tests.py -u -i -t RUN_NONE (or some variation)<br>2) coverage combine<br>3) coverage html<br></div></div>4) read the nice reports in the htmlcov/ directory<br clear="all">
<br><br>-- <br>Sean Robinson<br><br><br>