<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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><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>-- <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></div>