On Wed, Apr 22, 2015 at 11:26:14AM -0500, Ian Cordasco wrote: > On a separate thread Cory provided an example of what the hints would look > like for *part* of one function in the requests public functional API. > While our API is outwardly simple, the values we accept in certain cases > are actually non-trivially represented. Getting the hints *exactly* correct > would be extraordinarily difficult. I don't think you need to get them exactly correct. The type-checker does two things: (1) catch type errors involving types which should not be allowed; (2) allow code which involves types which should be allowed. 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. -- Steve
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4