This assumes:
- the dev is thinking about the API
- the dev has the knowledge and experience to do it
- the dev has the resource/constraints that allow to do so
- dev has an interest in doing so
- this is a good investment for that particular project
Thinking in black and white does not make for good language design.
I'm glad Guido designed Python and said no to so many requests to make it no Python. Because he sure been pressured to.
> When you’ve worked on a sufficiently large and complex code base maybe you’ll understand.
I do.
I also understand Python projects that have a favorable cost/benefit ratio for type hints are not that many.
When you're used to hammer you see everything as a nail, and people loving a specific language feature tend to want it everywhere.
A huge number of dev in the Python community are not professional nor even experienced programmers. And a equally big number of projects have a size or a nature that makes type hint a bad value.
When you’ve worked on a sufficiently diverse project base maybe you’ll understand.
Or when I'm doing data wrangling in jupyter and I never use type hints cause it's all just REPL rapid prototyping and I get autocomplete from the objects.
It's good for checking the internal logic, but being optional is important in the python context.
When you’ve worked on a sufficiently large and complex code base maybe you’ll understand.
Edit: coded in python for > 10 years. I prefer it over other languages, warts and all.