[Python-Dev] typeshed for 3rd party packages

[Cory Benfield]

On 24 April 2015 at 15:21, Steven D'Aprano <steve at pearwood.info> wrote:

> If the type hints are wrong, there are two errors: false positives, when
> code which should be allowed is flagged as a type error; and false
> negatives, when code which should be flagged as an error is not.
> Ideally, there should be no false positives. But false negatives are not
> so important, since you will still be doing runtime checks. All that
> means is that the static type-checker will be a little less capable of
> picking up type errors at compile time.

I think that's a rational view that will not be shared as widely as I'd like.

Given that the purpose of a type checker is to catch bugs caused by
passing incorrectly typed objects to a function, it seems entirely
reasonable to me to raise a bug against a type hint that allows code
that was of an incorrect type where that incorrectness *could* have
been caught by the type hint. Extending from that into the general
ratio of "reports that are actually bugs" versus "reports that are
errors on the part of the reporter", I can assume that plenty of
people will raise bug reports for incorrect cases as well.

>From the perspective of sustainable long-term maintenance, I think the
only way to do type hints is to have them be sufficiently exhaustive
that a user would have to actively *try* to hit an edge case false
negative. I believe that requests' API is too dynamically-typed to fit
into that category at this time.

PS: I should mention that, as Gary Bernhardt pointed out at PyCon,
people often believe (incorrectly) that types are a replacement for
tests. For that reason I feel like underspecified type hints are
something of an attractive nuisance. Again, I really think this is a
case of do it properly or not at all.