Get mypy itself type-checking cleanly under --strict-optional

[gnprice]

One necessary milestone toward making --strict-optional a recommended thing to use; the default; and ultimately the only mode (following what PEP 484 already says) will be for the mypy implementation itself to pass type-checking under --strict-optional. This is a tracking task for that goal.

[gnprice]

As of a version from master yesterday (commit 67d89b9e7 from 2016-07-27), this produced 480 error messages (counted with mypy -p mypy --strict-optional 2>&1 | grep -cP '^\S*:\d+: ') and 728 total lines of output. So there's some work to do.

I went through these errors to try to sort out which ones are bugs in mypy in its role as the type-checker, either in the --strict-optional code or exposed here by --strict-optional, and which ones are bugs in mypy as a statically-typed Python codebase.

Detailed notes here:
https://paper.dropbox.com/doc/Mypy-strict-optional-issues-UQPcKDn5VDdSXQme37o1G
and data here:
https://gist.github.com/gnprice/6d0413f022ca2a17d3d2bb1d4b96fbae

Short summary:

• 9 issues in mypy as the type-checker cause errors, totalling 144 lines. Of these, at least 5 are easy to work around in the target codebase; the other 4 cause 139 lines of error messages.
• 4 issues make various error messages less helpful than our usual standard of error-message quality, which could slow down fixing the None/Optional-related type errors in a codebase.
• 1 issue in the subprocess stub causes 2 messages.
• 334 lines of errors appear to be genuine issues in mypy as the target codebase.

I'll locate or file individual issues for the bugs in mypy-as-type-checker.

I think a lot of the 334 lines of issues in mypy-as-target-codebase will be straightforward to fix, many of them in large swaths, by adding Optional in appropriate places and is None checks in others. These often have the effect that adding Optional in one place causes a new error to show up in another place, so it can be hard to track progress. Probably we should fix the bugs in mypy-as-type-checker first, though, and work around any we don't yet fix, before making a big push to sort out the types.

[gnprice]

Two of the issues are

• Type inference of list comprehension and Optional[t] #1734 -- one error, easy to work around locally
• Conditional expression with branches of type None and T should be Optional[T], not object #1820 -- 13 errors, would be much better to fix

I think the other issues are as yet unfiled -- I'll start filing them.

[gnprice]

Filed also #1956, #1957, and #1958.

The three issues that cause errors in many places are #1956, #1957, #1820.

There are four more issues (in addition to #1734 and #1958) that cause an error in just one place each and probably aren't hard to just work around where they occur. Should definitely be filed and fixed, but I'm going AFK just now -- so as a temporary breadcrumb, here they are by the shorthand titles I gave them in my notes:

• Tuple and empty container
• type update due to assignment
• subtype on Callable neglecting optionality of args
• list slices should be effectively covariant

[ddfisher]

FYI, for counting error messages, instead of piping mypy's output through grep you can use --suppress-error-context.