Live data from Hacker News

Python Type Checker Comparison: Empty Container Inference

pyrefly.org

31–40 of 59 posts

Re: Python Type Checker Comparison: Empty Container Inference

#31
post #20

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?

If you're referring to the `first_three_lines` example in strategy 3, Mypy would give the same error even if we changed the return value to something unrelated like `return ["something"]`.

Re: Python Type Checker Comparison: Empty Container Inference

#32
post #28
post #24

Earlier 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?

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

#33
post #28

Earlier 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.

Thanks linsomniac and exyi. I didn't realize Python's type hints are checked by linters, not the compiler. Learned something today.

Re: Python Type Checker Comparison: Empty Container Inference

#34

I 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..

> TypeAlias, Generic

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

#35
post #3

I 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.

Annotating empty collections is one of the few places you need to annotate outside function signatures. It's not a big deal. It doesn't happen that often.

Re: Python Type Checker Comparison: Empty Container Inference

#36
post #6

My 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.

The type hints are not even enforced at runtime. They are mostly documentation.

Re: Python Type Checker Comparison: Empty Container Inference

#37
post #18

Is 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.

The only language I'm aware of that's a bit like that is rpython, but it's the other way round: designed for python to compile to it. If you think about it, you get more benefit from the typed language being the base one, as the compiler or JIT can make more assumptions, producing faster code . Typescript had no alternative but to do it the other way, since it's a lot harder to get things adopted into the browser than to ship them independently.

Re: Python Type Checker Comparison: Empty Container Inference

#38
post #18

Is 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.

You can compile F# to Python with Fable https://github.com/fable-compiler/Fable.Python

Re: Python Type Checker Comparison: Empty Container Inference

#40
post #39

Only 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?"

It's actually a fairly frequent fact of programming language development that type resolution can change across versions. Haskell famously has a ton of extensions that enhance the type system in various, potentially incompatible ways.

In fact the question of whether a code type-checks is itself undecidable.

Post reply on HN