> the last project I encountered in a professional capacity in Python where optional type hinting was used but wasn't always accurate which was a special sort of hell.
But that's the entire purpose of optional type hinting. If the hints had to be accurate, you'd have mandatory typing, not optional hinting.
No, optional type hinting means there's sometimes not a hint. Having a hint and then passing some type that's not that is wrong and hell.
Python's type hinting is horrible.
It's not checked, it's not required, and the bolted on syntax is ugly.
Even if the types were checked, they'd still fail at runtime and some code paths wouldn't get exercised.
We need a family of "near-scripting" languages like Go that check everything AOT, but that can be interpreted.
> It's not checked, it's not required,
It is both of those if you use a typechecker, which is the whole reason it exists (in fact, the first popular typechecker existed before the annotation syntax using type comments; type annotations were developed specifically so that it could be accommodated in the language rather than becoming its own separate language.)
That's the problem! The code should not run if the types are wrong. Having an external tool is an antipattern.
Having to rely on process for validity is a recipe for bad. We already know how the greater python community has been with requirements.txt and dependencies. I've spent days fixing this garbage.
It's a tooling problem. Good tools make good habits part of the automation and stop you from having to think about it.
You are talking about misleading type hints, not optional ones. Optional means they don’t have to be added. Wrong typehints are so much worse than missing ones.
I think the purpose of optional type hinting is that you don't have to add it everywhere all at once, not that it doesn't have to be accurate. I guess you could split hairs and say "hint" doesn't imply perfect accuracy, but... adding a language feature that can lie really seems to have a lot of downsides vs upsides; whereas at least optional has obvious migration benefits.
You could have optional type hints where the runtime would still yell at you - maybe even from just an optional flag - if you returned a string out of a function that should return an int.
Because as-is, once you have those function that says it returns an int but returns a string instead, etc, in a big codebase, your editor tooling gets really confused and it's way worse to work through than if the hints weren't there at all.
(And there are tools in Python that you can use to inspect and verify the accuracy. But those tools are also... optional... And if you start to apply them to a codebase where they weren't used, it can be very time-consuming to fix everything...)
> And there are tools in Python that you can use to inspect and verify the accuracy. But those tools are also... optional... And if you start to apply them to a codebase where they weren't used, it can be very time-consuming to fix everything...
How is that "bad" solution different from this "good" one?
> You could have optional type hints where the runtime would still yell at you - maybe even from just an optional flag - if you returned a string out of a function that should return an int.
If it's built in to the runtime you get a lot of potential benefits:
- you don't need to install additional packages
- you could have (because you don't want to hurt prod perf by checking all the time) dev-mode with warnings by default on execution and a prod-mode where they're ignored
- you can then have people in the dev environment catching things as they write/run/test their code vs only whenever they run the third party tool (which it seems a lot of people don't set up for even run-on-every-commit)
Let's flip the question around! What do you think are the benefits to making it easy to add misleading incorrect type hints?