In the example given in the article i think the correct behavior would have been to infer the type backwards from the return type of the function. Is that not why mypy actually errors here?
Python Type Checker Comparison: Empty Container Inference
31–40 of 59 posts
Re: Python Type Checker Comparison: Empty Container Inference
#32Earlier quoted context omitted.
Python does not need that, as it has built-in type annotation support. The annotation is any expression, so you can in theory express anything a custom type-only language would allow you (although you could make it less verbose and easier to read). However, the it IMHO just works much worse than TS because: * many libraries still lack decent annotations * other libraries are impossible to type because of too much dyn…
Thanks for helping me understand. I wasn't aware of Python's type annotation support. I did some quick research and learned that type annotations don't cause compile errors even when there are type errors. Is that why type checkers like Pyrefly exist?
Re: Python Type Checker Comparison: Empty Container Inference
#33Earlier quoted context omitted.
Thanks for helping me understand. I wasn't aware of Python's type annotation support. I did some quick research and learned that type annotations don't cause compile errors even when there are type errors. Is that why type checkers like Pyrefly exist?
Correct, currently in Python the type checking is implemented more in a linting phase than in a compiling or runtime phase. Though you can also get it from editors that do LSP, they'll show you type errors while editing the code.
Re: Python Type Checker Comparison: Empty Container Inference
#34I can't help but find type hints in python to be..goofy? I have a colleague who has a substantial C++ background and now working in python, the code is just littered with TypeAlias, Generic, cast, long Unions etc.. this can't be the way..
This is mitigated by modern (3.12+) generic and `type` syntax, which just looks like any other static language.
Re: Python Type Checker Comparison: Empty Container Inference
#35I think it would be worth mentioning that in normal use (strict mode) Pyright simply requires you to add type annotations to the declaration. Occasionally mildly annoying but IMO it's clearly the best option.
It's not "mildly annoying". I don't enable strict mode on multiple projects because people don't want to type anything outside of function signatures. Inferring the type from the first use is 100% the correct choice because this is what users want 99% of the time, for the rest you can provide type information.
Re: Python Type Checker Comparison: Empty Container Inference
#36My favorite part about the type annotations in python is that it steers you into a sane subset of the language. I feel like it's kind of telling that python is this super dynamic language but the type annotations aren't powerful enough to denote all that craziness.
Re: Python Type Checker Comparison: Empty Container Inference
#37Is there a compile-to-Python language with built-in type safety, similar to how TypeScript transpiles to JavaScript? I'm aware of Mojo and mypyc, but those compile to native code/binaries, not Python source.
Re: Python Type Checker Comparison: Empty Container Inference
#38Is there a compile-to-Python language with built-in type safety, similar to how TypeScript transpiles to JavaScript? I'm aware of Mojo and mypyc, but those compile to native code/binaries, not Python source.
Re: Python Type Checker Comparison: Empty Container Inference
#39Re: Python Type Checker Comparison: Empty Container Inference
#40Only Python, is a language soooo dynamic, that the question "Does this code type-checks?" may get the valid response: "With which of the 5 existing type checkers?"
In fact the question of whether a code type-checks is itself undecidable.