[Python-Dev] typeshed for 3rd party packages (original) (raw)

Cory Benfield cory at lukasa.co.uk
Fri Apr 24 16:44:45 CEST 2015

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.

More information about the Python-Dev mailing list