Repository navigation
Get mypy itself type-checking cleanly under --strict-optional #1955
Description
Activity
As of a version from master yesterday (commit
67d89b9e7from 2016-07-27), this produced 480 error messages (counted withmypy -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-optionalcode 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/6d0413f022ca2a17d3d2bb1d4b96fbaeShort 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
subprocessstub 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
Optionalin appropriate places andis Nonechecks in others. These often have the effect that addingOptionalin 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.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.
- Type inference of list comprehension and
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
- added this to the milestone
on Aug 4, 2016 FYI, for counting error messages, instead of piping mypy's output through grep you can use
--suppress-error-context.- removed this from the milestone
on Mar 29, 2017 - added 2 commits that reference this issue
on Oct 24, 2017
One necessary milestone toward making
--strict-optionala 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.