3 ms·

Can you add some examples of the things users care about that aren't well covered by this? I empathize with everyone who wants a feature comparison chart so the

Can you add some examples of the things users care about that aren't well covered by this? I empathize with everyone who wants a feature comparison chart so they can be confident switching without unknowingly losing important safety checks.

dcre 10mo ago
I think the idea is not that there are features that aren’t listed, but rather that if a typechecker supports 10 features people care about and is missing 10 that people don’t really use, it will look a lot worse on a list like this than a typechecker with 100% compliance, when in practice it may not really be worse at all. Edit: Based on this other comment, the point was also about things not covered by the spec. “The spec mostly concerns itself with the semantics of annotations, not diagnostics or inference.” https://news.ycombinator.com/item?id=46296360 https://news.ycombinator.com/item?id=46296360
codys 10mo ago
The chart does not describe speed (either in general or in any particular case). Speed/performance/latency is a thing users care about that is not included in the feature list.
- SmileyKeith 10mo ago
  Yea that one is fine and well covered in the blog post, and pretty easy to spot in light testing. I'm much more worried about the ones that are harder to spot until you have a false negative that turns into a real bug which would be caught by 1 tool and not another.
- jghn 10mo ago
  I can't recall a single time that type-checker speed was the limiting factor for me.
  - theLiminator 10mo ago
    I can't say I've been bottlenecked on it, but I've certainly been bothered by it.
hauntsaninja 10mo ago
The conformance test suite is currently mostly focused on “what does an explicit type annotation mean” A shared spec for this is important because if you write a Python library, you don’t want to have to write a different set of types for each Python type checker Here are some things the spec has nothing to say about: Inference You don’t want to annotate every expression in your program. Type checkers have a lot of leeway here and this makes a huge difference to what it feels like to use a type checker. For instance, mypy will complain about the following, but pyright will not (because it infers the types of unannotated collections as having Any): x = [] x.append(1) x[0] + "oops" The spec has nothing to say about this. Diagnostics The spec has very little to say about what a type checker should do with all the information it has. Should it complain about unreachable code? Should it complain if you did `if foo` instead of `if foo()` because it’s always true? The line between type checker and linter is murky. Decisions here have nothing to do with “what does this annotation mean”, so are mostly out of scope from the spec. Configuration This makes a huge difference when adapting huge codebases to different levels of type checking. Also the defaults really matter, which can be tricky when Python type checkers serve so many different audiences. Other things the spec doesn’t say anything about: error messages quality, editor integration, speed, long tail of UX issues, implementation of new type system features, plugins, type system extensions or special casing And then of course there are things we would like to spec but haven’t yet!
- maleldil 10mo ago
  > but pyright will not (because it infers the types of unannotated collections as having Any) This is incorrect. pyright will infer the type of x as list[Unknown].
  - hauntsaninja 10mo ago
    Unknown has the exact same type system semantics as Any. Unknown is a pyright specific term for inferred Any that is used as the basis for enabling additional diagnostics prohibiting gradual typing. Notably, this is quite different from TypeScript’s unknown, which is type safe.

dcre 10mo ago

I think the idea is not that there are features that aren’t listed, but rather that if a typechecker supports 10 features people care about and is missing 10 that people don’t really use, it will look a lot worse on a list like this than a typechecker with 100% compliance, when in practice it may not really be worse at all. Edit: Based on this other comment, the point was also about things not covered by the spec. “The spec mostly concerns itself with the semantics of annotations, not diagnostics or inference.” https://news.ycombinator.com/item?id=46296360 https://news.ycombinator.com/item?id=46296360

codys 10mo ago

The chart does not describe speed (either in general or in any particular case). Speed/performance/latency is a thing users care about that is not included in the feature list.

SmileyKeith 10mo ago
Yea that one is fine and well covered in the blog post, and pretty easy to spot in light testing. I'm much more worried about the ones that are harder to spot until you have a false negative that turns into a real bug which would be caught by 1 tool and not another.
jghn 10mo ago
I can't recall a single time that type-checker speed was the limiting factor for me.
- theLiminator 10mo ago
  I can't say I've been bottlenecked on it, but I've certainly been bothered by it.

hauntsaninja 10mo ago

The conformance test suite is currently mostly focused on “what does an explicit type annotation mean” A shared spec for this is important because if you write a Python library, you don’t want to have to write a different set of types for each Python type checker Here are some things the spec has nothing to say about: Inference You don’t want to annotate every expression in your program. Type checkers have a lot of leeway here and this makes a huge difference to what it feels like to use a type checker. For instance, mypy will complain about the following, but pyright will not (because it infers the types of unannotated collections as having Any): x = [] x.append(1) x[0] + "oops" The spec has nothing to say about this. Diagnostics The spec has very little to say about what a type checker should do with all the information it has. Should it complain about unreachable code? Should it complain if you did `if foo` instead of `if foo()` because it’s always true? The line between type checker and linter is murky. Decisions here have nothing to do with “what does this annotation mean”, so are mostly out of scope from the spec. Configuration This makes a huge difference when adapting huge codebases to different levels of type checking. Also the defaults really matter, which can be tricky when Python type checkers serve so many different audiences. Other things the spec doesn’t say anything about: error messages quality, editor integration, speed, long tail of UX issues, implementation of new type system features, plugins, type system extensions or special casing And then of course there are things we would like to spec but haven’t yet!

maleldil 10mo ago
> but pyright will not (because it infers the types of unannotated collections as having Any) This is incorrect. pyright will infer the type of x as list[Unknown].
- hauntsaninja 10mo ago
  Unknown has the exact same type system semantics as Any. Unknown is a pyright specific term for inferred Any that is used as the basis for enabling additional diagnostics prohibiting gradual typing. Notably, this is quite different from TypeScript’s unknown, which is type safe.