5 ms·

kinda mixed on this - why not just contribute to the community tool? - there's already a major split in Python type-checking tools, if there's a third that do

by mwt 2y ago

kinda mixed on this - why not just contribute to the community tool? - there's already a major split in Python type-checking tools, if there's a third that doesn't agree with either of them it'll be a mess for projects to deal with - astral has been hiring like mad recently and has yet to communicate that they can actually make money ($5 million doesn't last forever) - does it actually exist? is this currently a closed-source codebase, or is "we're building" future tense?

dcreager 2y ago
> does it actually exist? is this currently a closed-source codebase, or is "we're building" future tense? From the thread: > We haven't publicized it to-date, but all of this work has been happening in the open, in the Ruff repository.
- mwt 2y ago
  thanks, I didn't know it was a thread because of the login wall
  - dcreager 2y ago
    np! I also posted a link to Charlie's Bluesky cross-post, which you can read without logging in to anything: https://news.ycombinator.com/item?id=42870359 https://news.ycombinator.com/item?id=42870359
shlomo_z 2y ago
- They usually so a pretty good job adhering to standards - re: the money: https://news.ycombinator.com/item?id=42869358 https://news.ycombinator.com/item?id=42869358
- mwt 2y ago
  Unfortunately that doesn't answer the question
zem 2y ago
> - 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.
- VeejayRampay 2y ago
  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
- mwt 2y ago
  > 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
  - zem 2y ago
    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.

by mwt 2y ago

dcreager 2y ago

> does it actually exist? is this currently a closed-source codebase, or is "we're building" future tense? From the thread: > We haven't publicized it to-date, but all of this work has been happening in the open, in the Ruff repository.

mwt 2y ago
thanks, I didn't know it was a thread because of the login wall
- dcreager 2y ago
  np! I also posted a link to Charlie's Bluesky cross-post, which you can read without logging in to anything: https://news.ycombinator.com/item?id=42870359 https://news.ycombinator.com/item?id=42870359

shlomo_z 2y ago

- They usually so a pretty good job adhering to standards - re: the money: https://news.ycombinator.com/item?id=42869358 https://news.ycombinator.com/item?id=42869358

mwt 2y ago
Unfortunately that doesn't answer the question

zem 2y ago

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

VeejayRampay 2y ago
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
mwt 2y ago
> 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
- zem 2y ago
  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.