Add a linter to ensure kwargs are not being called as args.

[rishig]

Update: This is blocked on moving to Python 3.

Ideally we could come up with something fast enough that it could run as a part of lint-all, but I think a travis-only solution would still be acceptable (or a version that just runs on the diff locally).
git grep 'def ' | grep '=' | wc returns 382.

Some implementation ideas:

• For each function that takes kwargs, insert a fake kwarg before the list, and then run mypy. So e.g. the script would turn anything that looked like def f(a, b=5) into def f(a, fake='', b=5), adjust the type: accordingly, and then run tools/run-mypy.
• Use a simple heuristic like the git grep above to find all the functions with kwargs, and then git grep for each of those functions in a loop and check how it is called. If we only do this for select files/directories I imagine the 382 could come down to 1-200.
• Adapt or find something in pylint. E.g. this was added in 2009: https://lists.logilab.org/pipermail/python-projects/2009-November/002090.html (we need something much simpler than what they are trying to do; all we care is that the number of non-kwargs given = the number of non-kwargs in the function def, since mypy is taking care of the rest)
• Convince Guido to add this as an option to mypy

[kaushik-rohit]

@rishig hi i would like to work on this

[rishig]

Cool! I should say: the current thought is that we should only do this if we can do it mostly correctly (i.e. not to use simple heuristics that get 90%, and then have a large list of exclusions.) Do you have an idea for how you might implement it?

[timabbott]

@rwbarton suggested one way we could do this: https://chat.zulip.org/#narrow/stream/tools/topic/linters ; it sounds like potentially the right approach would be to add an optional flag to mypy to do this.

[timabbott]

I think for this issue, we just want to wait for Python 3 and the use the new Python 3 feature where you do def f(a, *, b=5) and it enforces only one positional argument.

[timabbott]

Closing this issue; I think we can start using that syntax where needed once we're on Python 3, but we're unlikely to make the change just because this issue is open.