9 ms·

There really is a cost, in the form of having to rerun code a dozen more times to catch unresolved type errors. But AFAIK, that's it. Can I ask what I'm missing

There really is a cost, in the form of having to rerun code a dozen more times to catch unresolved type errors. But AFAIK, that's it. Can I ask what I'm missing? What cost of this (optional) static typing are folks talking about? IMO this is worth it, since the goal is less about eliminating runtime errors or other errors, and more about encouraging documentation in code rather than in comments/docstrings. This makes reading code simpler, not less so.

bakery2k 7y ago
In a language like Python that encourages duck typing, type hints can become extremely complex [1] and can get in the way of the ideal of "executable pseudocode" [2]. [1] https://mail.python.org/pipermail/python-dev/2015-April/139267.html https://mail.python.org/pipermail/python-dev/2015-April/1392... [2] https://twitter.com/dabeaz/status/981832805540909056 https://twitter.com/dabeaz/status/981832805540909056
- darkkindness 7y ago
  Thanks for the links! Those fully specified frankentypes are indeed atrocious, and no sane person should ever need to read them. That being said, isn't "Any" meant to act as a wildcard, used precisely for ignoring the unimportant parts of the type? Specifying huge and rigorously correct types just seem like an eager misuse of type hints to me. At the same time, adding the capabilility for complexity the language does encourage complexity, doesn't it? (Rust comes to mind.) So I admit what I just said isn't much of an argument -- frankentype hints _will_ be written, and therefore we _will_ have to suffer them someday...
- bjoli 7y ago
  Does anyone think it is a good idea to accept anything with a __str__ in requests.get? That seems like an awful idea. I am more of a dynamically but strict kind of guy, and this seems like a good way to get weird behaviour.
- banannaise 7y ago
  [2] is (1) horrifying, and (2) descriptive of something Python is really good at (handling complexly-typed input datasets without requiring complex declarations). The solution to that code is to remove the type hint, because you don't need it, because it simply describes the type of the input data. edit: Several far better Python developers than I also said as much in the tweet replies.

bakery2k 7y ago

In a language like Python that encourages duck typing, type hints can become extremely complex [1] and can get in the way of the ideal of "executable pseudocode" [2]. [1] https://mail.python.org/pipermail/python-dev/2015-April/139267.html https://mail.python.org/pipermail/python-dev/2015-April/1392... [2] https://twitter.com/dabeaz/status/981832805540909056 https://twitter.com/dabeaz/status/981832805540909056

darkkindness 7y ago
Thanks for the links! Those fully specified frankentypes are indeed atrocious, and no sane person should ever need to read them. That being said, isn't "Any" meant to act as a wildcard, used precisely for ignoring the unimportant parts of the type? Specifying huge and rigorously correct types just seem like an eager misuse of type hints to me. At the same time, adding the capabilility for complexity the language does encourage complexity, doesn't it? (Rust comes to mind.) So I admit what I just said isn't much of an argument -- frankentype hints _will_ be written, and therefore we _will_ have to suffer them someday...
bjoli 7y ago
Does anyone think it is a good idea to accept anything with a __str__ in requests.get? That seems like an awful idea. I am more of a dynamically but strict kind of guy, and this seems like a good way to get weird behaviour.
banannaise 7y ago
[2] is (1) horrifying, and (2) descriptive of something Python is really good at (handling complexly-typed input datasets without requiring complex declarations). The solution to that code is to remove the type hint, because you don't need it, because it simply describes the type of the input data. edit: Several far better Python developers than I also said as much in the tweet replies.