4 ms·
Despite this: > Even if the Python runtime did check all the type hints at runtime, then it would still be too late. I don’t want a fancy type exception at run
by just-ok 4y ago
Despite this:
> Even if the Python runtime did check all the type hints at runtime, then it would still be too late. I don’t want a fancy type exception at runtime. That already exists (most of the time). I want to know about type mismatches in advance.
You should check out Typeguard [1], which lets you add a @type_checked decorator to anything and get runtime type checking that's far better than e.g. a random blowup when you split() on an integer. It does introduce a significant amount of overhead, but it's still useful during development alongside type hints to avoid some of the pitfalls from this article.
In another vein, Any should definitely be used sparingly. For the foo() function outlined in the article, Union[str, int] offers more precision. In fact, you could even argue that using Any is a code smell.
Overall, though, I agree with most of the sentiment in this article. I find myself using type hints more as documentation than anything else, since their true ability to prevent type-related runtime bugs is very limited. Documentation has the same qualms the author outlines, anyway:
> You can not be sure that they are correct. [...] They waste mental energy when reading code, they create new maintenance burdens, and they are potentially deceiving: You cannot trust them.
But they're still slightly better than docstrings...
[1]: https://typeguard.readthedocs.io/en/latest/userguide.html https://typeguard.readthedocs.io/en/latest/userguide.html
- riyadparvez 4y agoThere's also bear-type for runtime type checking: https://github.com/beartype/beartype https://github.com/beartype/beartype.
- pydry 4y agoI've been perplexed as to why this hasnt been built in to the python runtime since day 1.
- bayesian_horse 4y agoPython was first released in 1991.
- pydry 4y agoAnd day 1 of when type hints was introduced was in 2014.
- toolslive 4y agoType inference has been around (as in "used in programming languages") since the early 1970s. In the beginning python hit a sweet spot: glue code that wasn't exactly write once, too difficult to do in bash, and too small to go all the way and use C++. However, it was not without its own design issues.
- captainmuon 4y agoDo you know if there is a way to do runtime type checking in the whole program with typeguard, beartype or something else? As far as I know you have to go through and add decorators manually. Typeguard had a profiler hook that almost got it right, but is being removed. Ideally I would want to say 'python3 -m typecheck myprogram.py' and it would run typechecking everything in my code (but maybe not in library code).
- just-ok 4y agoI believe you're describing MyPy? http://mypy-lang.org/ http://mypy-lang.org/
- captainmuon 4y agoMyPy is great but it checks "offline" or "at compile time" if you know what I mean. It is like a super linter, and doesn't actually run the program (AFAIK). What I'm looking for is more like a debugger or profiler. It actually runs the program, and then reports if at any time the type annotations deviate from the actual types. (I guess the general case is too costly - think of typechecking a huge list - but for most cases it should be possible.) There are runtime type checkers for python, but the all require modifying the code, and they don't work properly on the main module.