Pyright had 100% conformance until recently. There was a new PEP that was accepted which required some new conformance tests, which no type checker has added support for yet.
> people looking at the low pass rates for mypy and ty and concluding they must not be very useful
Yeah, that would be the wrong takeaway from this blog. The point of the blog was to add context to what the conformance results mean and clarify their limitations, since I saw quite a few people sharing links to the tracker online w/o context.
This would be an insta-switch feature for me! Jaxtyping is a great idea, but the runtime-only aspect kills it for me - I just resort to shape assertions + comments, but it's a pretty poor solution.
A follow-up question: Google's old `tensor_annotations` library (RIP) could statically analyse operations - eg. `reduce_sum(Tensor[Time, Batch], axis=0) -> Tensor[Batch]`. I guess that wouldn't come with static analysis for jaxtyping?
It's acknowledged at the end of the "infer any" strategy, but perhaps worded poorly.
> To improve type safety in these situations, type checkers that infer Any for empty containers can choose to generate extra type errors that warn the user about the insertion of an Any type. While this can reduce false negatives, it burdens developers by forcing them to explicitly annotate every empty container in order to silence the warnings.
ie: "type checkers that don't infer container types can emit an error and require users to annotate"
I missed that. At least pyright will only emit an error if `typeCheckingMode` is strict (which forbids `Unknown`). It will happily treat `Unknown` as `Any` in basic mode.
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"]`.
Requiring the annotations on empty containers is the only way to have type safety if the type checker cannot infer the type of the container, like Pyright.
If the type checker can infer a type then the annotation would only be required if the inferred type doesn't match the user's intent, which means one would need to add fewer annotations to an arbitrary working-but-unannotated program to satisfy the type checker.
Yes but also having more complicated type inference makes the actual type checking less useful as a check. You see that in languages with global type inference too.
Adding explicit types strategically (e.g. in function signatures) tells the compiler (and readers) explicitly what the type should be, so if you add code that violates that it gives you an error instead of silently inferring a different type.
(pyrefly maintainer here) If you haven't already, please file an issue for that crash on the [Pyrefly repo](https://github.com/facebook/pyrefly) as well :)
Pyrefly (a new language server and type checker for Python) now includes built-in support for Pydantic, a popular Python library for data validation and parsing. Previously, the only type checker that supported Pydantic was Mypy, via a plugin.
reply