ocamoss

I'm not impressed, it's an AI-generated apology. A quick skim of their code or commit history makes that obvious that this project's development methodology was clearly flawed, and only someone who turned their brain off would have advertised those results in the first place.

Maybe it's like Meta not releasing the big version of Llama 4 a year or two ago

Everything? The blog post and PEP have almost nothing to do with each other lol

> commented/documented code at best

Machine-checked documentation is always valuable, IMO

Running more type checkers isn't really about strictness. The main benefit to library maintainers is to make sure that their APIs are compatible with whatever tools their users run.

This wouldn't really be an issue for most other languages, but Python's typing ecosystem is uniquely fragmented, with only partial standardization between several popular tools.

There's an `implicit-any` error code

Maintainer here: that's not the expected experience. If you're able to share details about the project & file an issue on our Github, we can try to reproduce it and figure out what's going on.

thanks! :-)

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.

Pyrefly's Django support is documented here: https://pyrefly.org/en/docs/django/

I believe Zuban also has some form of Django support, but I'm unable to locate the docs

We're working on statically checking Jaxtyping annotations in Pyrefly, but it's incomplete and not ready to use yet :)

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"

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.

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

Pyrefly actually does have (experimental) support for Pydantic! https://pyrefly.org/en/docs/pydantic/