<div dir="ltr">A couple of things I forgot to mention:<div><br></div><div>* One relevant consequence is that, to add annotations on the code, scikit-learn should depend on the "typing"[1] module which contains some of the basic names imported and used in annotations. It's a stdlib module in python 3.5, but the PyPI package backports it to python 2.7 and newer (I'm not sure how it works with Python 2.6, which might be an issue)</div><div>* As an example of the kind of bugs that mypy can find, someone here already found a documentation bug in the sklearn.svm.SVC() initializer; the "kernel" parameter is described as "string"[2], when it's actually a "string or callable" (which can be read in the "small print" description of the argument). That kind of slips would be automatically prevented if declared as an annotation with mypy on the CI. Also it would be more clear what is the signature of the callable directly instead of looking up additional documentation on kernel functions or digging into the source</div><div><br></div><div>[1] <a href="https://pypi.python.org/pypi/typing">https://pypi.python.org/pypi/typing</a><br></div><div>[2] <a href="http://scikit-learn.org/stable/modules/generated/sklearn.svm.SVC.html#sklearn.svm.SVC">http://scikit-learn.org/stable/modules/generated/sklearn.svm.SVC.html#sklearn.svm.SVC</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 5:15 PM, Daniel Moisset <span dir="ltr"><<a href="mailto:dmoisset@machinalis.com" target="_blank">dmoisset@machinalis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Jul 29, 2016 at 8:57 PM, Gael Varoquaux <span dir="ltr"><<a href="mailto:gael.varoquaux@normalesup.org" target="_blank">gael.varoquaux@normalesup.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Can you summarize once again in very simple terms what would be the big<br>
benefits?<br></blockquote><div><br></div></span><div>Benefits for regular scikit-learn users</div><div><br></div><div>1. Reliable information on method signatures in a standarized way ("reliable" in the sense of "automatically verified")</div><div>2. Better integration with tools supporting PEP-484 (editors, documentation tools). This is a small set now, but I expect it to grow (and it's also an egg and chicken problem, support has to start somewhere)</div><div><br></div><div>Benefits for scikit-learn users also using mypy and/or PEP-484 (probably not a large set, but I know a few people :) )</div><div><br></div><div>0. Same as the rest of the users</div><div>1. Early detection of errors in own code while writing code based on SKL</div><div>2. Making own code more readable/explicit by annotating functions that receive/return SKL types (and verifying that annotations)</div><div><br></div><div>Benefits for scikit-learn developers</div><div><br></div><div>1. Some extra checks that changes keep internal consistency</div><div>2. (Future) possible simplification of typing information in docstrings, which would make themselves redundant (this would require updating doc generators)</div><div><br></div><div>Regarding the cost for contributing, an scenario where you get a CI error due to mypy would be because:</div><div><br></div><div>* the change in the code somewhat changed the existing accepted/returned types, which is a change in the API and should actually be verified</div><div>* the change in the code extended the signature of an existing function (what Andreas mentioned); in this situation it's similar to a PR that adds an argument and doesn't update the docstring (only that this is automatically caught).</div><div><br></div><div>WRT to the second issue, the error here might be confusing when using the "one line" syntax because arguments may "misalign" with their signatures. The multiline version (or the python3-only form) is safer in that sense (in fact, adding an argument there will not produce a CI problem because its unannotated and assumed to be "any type").</div><div> </div><div>Adding new modules/methods without no annotations wouldn't produce an error, just an incompleteness in the annotations</div><div><br></div><div>A possible source of problems like the one you mention is that the implementation of the annotated methods will be checked, and sometimes you'll get a warning about a local variable if mypy can't infer its type (it happens sometimes when assigning an empty list to a local, where mypy knows that it's a list but doesn't know the element type). But in that case I think the message you get is very obvious.</div><div><br></div></div><span class="">-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Daniel F. Moisset - <span style="font-size:small">UK Country Manager</span><div><a href="http://www.machinalis.com" target="_blank">www.machinalis.com</a></div><div>Skype: @dmoisset</div></div></div></div></div>
</span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Daniel F. Moisset - <span style="font-size:small">UK Country Manager</span><div><a href="http://www.machinalis.com" target="_blank">www.machinalis.com</a></div><div>Skype: @dmoisset</div></div></div></div></div>
</div>