> - why not just contribute to the community tool?
what community tool? mypy is written in python, and is non-incremental, whereas astral's goal is to build a fast, incremental type checker in rust. there is no way to get from one to the other via code contributions, they fundamentally need to start from scratch with their own architecture.
as for the split in type checking tools, it is not as bad as you think; the syntax and to a large extent the semantics of the type system are defined via a community process and standardised upon, and the various type checkers largely differ in their implementation details but not in their interpretation of the code. so you can freely use several different type checkers without fear of disagreement.
nah actually we should keep the slow, subpar tooling we got now because it came first
those people producing fantastic tools that have transformed the ecosystem of linting and packaging
should be working on it instead of working on transformative tech
> as for the split in type checking tools, it is not as bad as you think
I'm surprised you already know it's not as bad as I think - have you been able to use it? Working on a team that mixes mypy and pyright is pretty frustrating since they don't agree on everything (i.e. when one changeset passes on one and fails on the other) and I see no reason to believe the inconsistencies will become more rare when the number of opinions goes from two to three
i worked on pytype for several years, and occasionally had to support projects that wanted to use multiple type checkers. in my experience, there were definitely times when one type checker would pass some code and another one reject it, but not code that would strictly work on either one checker or another but not both. it could be a pain trying to keep the strictest type checker happy when the other ones passed your code, but usually once you did that you were fine.
also if you do find a case where two type checkers genuinely conflict on a piece of code, one or both of them would definitely like to see it as a bug report. if the underlying cause turns out to be undefined behaviour in the specs, the general typing community will work together to nail it down and the type checkers will all adapt. in general it is a very cooperative process that values the existence of a common set of standards, which is why I think having more type checkers will only improve the situation wrt nailing down corner cases in the specs.
I'm a little surprised to see you dismiss type-checkers disagreeing with each other - there are more than a few cases of mypy and pyright disagreeing and brushing them aside as rare enough to be irrelevant is in conflict with my experience over the years.
I'm happy you believe that the community can converge on unified standards - I wish I shared the optimism - but that's not where we're currently at and years-long efforts don't help me now. (For example, I'd love to use PEP 695 generics since I found a use case for them around 18 months ago but I can't until I can get away with not supporting 3.11, which is years out.) Maybe everything is perfect in 2028 or so - I'd be thrilled - but that doesn't help the pitch for annotations being a value add for people who are worried about the current jobs.
sorry, I didn't mean to sound dismissive of the problem, I just believe it is a problem that having more actively developed type checkers will make better rather than worse. with my type checker developer hat on, the end goal is not to have a single type checker and have the implementation be the spec, it's to have an evolving set of standards that (ideally) can express the patterns people want from python, and then have the type checkers work with those standards.
pep695 is a good example of how the spec is still evolving to try and make the explicit type system work better for python developers. dataclass transforms are perhaps an even better example - that's a pattern that is very specific to python and based on real world, non-typing-related ways in which people use the language, and which they wanted the annotation system to cover, and there was a collaborative effort to develop a way to do it.
also note that there are escape hatches like error suppression (e.g. if pyright likes some code but mypy wrongly thinks it's a type error, you can add a comment so that mypy ignores that one error while continuing to have pyright check it) and typing.cast (which is a directive all the type checkers honour, to say "trust me, this variable has this particular type whether or not you can verify it statically").
another thing to consider is that having type checking work interactively in the IDE is something a lot of people want, and pyright was developed specifically to support that feature. mypy, pytype, and pyre were all architected as batch type checkers, i.e. they need to run on a complete program as a standalone process, and it would have been anywhere from difficult to impossible to get them to support the type of incremental checking an IDE requires.
what community tool? mypy is written in python, and is non-incremental, whereas astral's goal is to build a fast, incremental type checker in rust. there is no way to get from one to the other via code contributions, they fundamentally need to start from scratch with their own architecture.
as for the split in type checking tools, it is not as bad as you think; the syntax and to a large extent the semantics of the type system are defined via a community process and standardised upon, and the various type checkers largely differ in their implementation details but not in their interpretation of the code. so you can freely use several different type checkers without fear of disagreement.