Closed jszopi closed 5 years ago
Type-based runtime checks may be the only way of making sure that users don't misuse the library without them embracing mypy
to the max. It can also catch some errors due to the library not having a 100% Any
coverage. One library that does runtime checks is pydantic
, but I haven't recently researched the shifting landscape.
Closing in favour of runtime type checking in #48.
A single
Any
type can seriously undermine the benefit from having a type checker. I've just spent quite a lot of time on getting the codebase to a strictmypy
type check level, so I don't feel like working on the 50+ errors that appear with the--disallow-any-expr
flag, but they could potentially hide severe type errors. A compromising alternative would be to monitor the output of--any-exprs-report
in CI, but unless that integrates nicely withcoverall
, it won't be useful. The brief report is currently:Note that this concern applies to user scripts as well. As soon as the user creates an annotated function to calculate a parameter for passing to a library function,
mypy
would deduceAny
for the type. This particular scenario is alleviated by having the user use the--strict
flag, which implies--disallow-untyped-defs
, but users may then get strongly discouraged by the type errors and start ignoringmypy
. They can still use explicitAny
too.