On 24 April 2015 at 15:21, Steven D'Aprano <st...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
