4 ms·

I think this is for the best. I used Pytype at Google years ago and while it's well written and the team was responsive, ultimately Python is not well suited f

I think this is for the best. I used Pytype at Google years ago and while it's well written and the team was responsive, ultimately Python is not well suited for type checking Python. It's compute intensive. I think the Ty people at Astral have the correct idea, and hope it'll work out. https://docs.astral.sh/ty/ https://docs.astral.sh/ty/

zhikanbumai 1y ago
In theory, nothing prevents the pytype team at Google to develop a new backend in a different language. In practice, there is no longer a pytype team at Google [https://news.ycombinator.com/item?id=40171125 https://news.ycombinator.com/item?id=40171125], which I suspect is the real reason for the discontinuation.
- ASinclair 1y ago
  There is still a team within Google in charge of this space.
- comex 1y ago
  To be fair, even if there is/were a team, I don’t know that writing a new backend from scratch would be a good use of their time. pytype apparently started before mypy or any of the other Python type checkers existed. [1] But at this point there’s mypy, pyright, pyre/pyrefly, Ty, and probably more I’m not thinking of. It sounds more useful to collaborate with one of those existing projects than to write yet another new type checker. Especially when, in my experience, each checker produces slightly different results on the same code, effectively creating its own slightly different language dialect with the associated fragmentation cost. In theory that cost could be avoided through more rigorous standardization efforts to ensure all the checkers work exactly the same way. But that would also reduce the benefit of writing a new type checker, since there would be less room to innovate or differentiate. [1] https://news.ycombinator.com/item?id=19486938 https://news.ycombinator.com/item?id=19486938
- zem 1y ago
  there is a new python team, we met up with them at pycon and had some nice conversations. as a former pytype dev I will be the first to admit that maintaining it as a legacy project without the context of having developed it over the years would not have been a pleasant experience at all, but also pytype, while very powerful at what it did, definitely had some flaws that put it firmly in the last generation of type checkers. the current generation (mostly ty and pyrefly right now, though major props to pyright for being ahead of the curve) is moving towards fast, incremental type checking with LSP integration, and pytype was never going to get there. it's fundamentally a slow, batch-based type checker, which will catch a lot of errors in your project, but which will never be usable as an incremental type checker within your ide. add that to the fact that it had a different philosophy of type checking from most of the other major checkers and you had users facing the issue that their code would be checked one way by pyright in the ide, and then a subtly different way by pytype in the CI pipeline. I loved my time working on pytype, and I would like to see some of its features added to pyrefly, but it has definitely been superseded by now.
LtWorf 1y ago
I'm personally just staying away from startups anywhere in my dependencies.
- deleted 1y ago
  [deleted]
- deleted 1y ago
  [deleted]
- vovavili 1y ago
  The cost of your dogmatic preference is your Python experience being more miserable than it should be. Astral's ruff and uv are widely adopted for a good reason, and there is no reason to think that ty will come any different.
  - LtWorf 1y ago
    There is a reason and a potential much bigger cost I'm avoiding, that you are conveniently ignoring.
rhaps0dy 1y ago
I've heard of `ty` too but recently I learned about Pyrefly, which is not in pre-production alpha, and is also Rust: https://pyrefly.org/ https://pyrefly.org/ Is there a good reason to avoid using Pyrefly?
- jolux 1y ago
  I believe Pyrefly is stricter, so it may be a better choice for new projects but harder to integrate into existing ones without type-checking.
  - denis- 1y ago
    I have a medium-sized codebase that is all green when running mypy with the strictest configuration possible. Pyrefly spits put around 200 errors for the same codebase. Most errors are related to SQLAlchemy.
    - rhaps0dy 1y ago
      I mean, sqlalchemy until very recently needed a mypy plugin to type correctly (https://docs.sqlalchemy.org/en/20/orm/extensions/mypy.html https://docs.sqlalchemy.org/en/20/orm/extensions/mypy.html), which was just deprecated in 2.0.0. Perhaps you should do the upgrade (https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html#orm-declarative-models https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html...) and try again?
    - samwgoldman 1y ago
      (Pyrefly dev here) Thanks for trying it out! If you have any feedback or bug reports, please don't hesitate to file issues on GitHub or find us on Discord. We have some open issues for SQLAlchemy (like [1]). I'm definitely curious to hear if there are any gaps from your perspective, having an already strictly-typed codebase. 1. https://github.com/facebook/pyrefly/issues/954 https://github.com/facebook/pyrefly/issues/954
- diggan 1y ago
  > Is there a good reason to avoid using Pyrefly? Wouldn't the other way around be easier for finding good tools? Figure out what matters to you, inspect if the project fulfills those needs and then go with it after making sure it works well for you. Regardless, a comparison between the two was posted to HN not too long time ago: https://news.ycombinator.com/item?id=44107655 https://news.ycombinator.com/item?id=44107655

zhikanbumai 1y ago

In theory, nothing prevents the pytype team at Google to develop a new backend in a different language. In practice, there is no longer a pytype team at Google [https://news.ycombinator.com/item?id=40171125 https://news.ycombinator.com/item?id=40171125], which I suspect is the real reason for the discontinuation.

ASinclair 1y ago
There is still a team within Google in charge of this space.
comex 1y ago
To be fair, even if there is/were a team, I don’t know that writing a new backend from scratch would be a good use of their time. pytype apparently started before mypy or any of the other Python type checkers existed. [1] But at this point there’s mypy, pyright, pyre/pyrefly, Ty, and probably more I’m not thinking of. It sounds more useful to collaborate with one of those existing projects than to write yet another new type checker. Especially when, in my experience, each checker produces slightly different results on the same code, effectively creating its own slightly different language dialect with the associated fragmentation cost. In theory that cost could be avoided through more rigorous standardization efforts to ensure all the checkers work exactly the same way. But that would also reduce the benefit of writing a new type checker, since there would be less room to innovate or differentiate. [1] https://news.ycombinator.com/item?id=19486938 https://news.ycombinator.com/item?id=19486938
zem 1y ago
there is a new python team, we met up with them at pycon and had some nice conversations. as a former pytype dev I will be the first to admit that maintaining it as a legacy project without the context of having developed it over the years would not have been a pleasant experience at all, but also pytype, while very powerful at what it did, definitely had some flaws that put it firmly in the last generation of type checkers. the current generation (mostly ty and pyrefly right now, though major props to pyright for being ahead of the curve) is moving towards fast, incremental type checking with LSP integration, and pytype was never going to get there. it's fundamentally a slow, batch-based type checker, which will catch a lot of errors in your project, but which will never be usable as an incremental type checker within your ide. add that to the fact that it had a different philosophy of type checking from most of the other major checkers and you had users facing the issue that their code would be checked one way by pyright in the ide, and then a subtly different way by pytype in the CI pipeline. I loved my time working on pytype, and I would like to see some of its features added to pyrefly, but it has definitely been superseded by now.

LtWorf 1y ago

I'm personally just staying away from startups anywhere in my dependencies.

deleted 1y ago
[deleted]
deleted 1y ago
[deleted]
vovavili 1y ago
The cost of your dogmatic preference is your Python experience being more miserable than it should be. Astral's ruff and uv are widely adopted for a good reason, and there is no reason to think that ty will come any different.
- LtWorf 1y ago
  There is a reason and a potential much bigger cost I'm avoiding, that you are conveniently ignoring.

rhaps0dy 1y ago

I've heard of `ty` too but recently I learned about Pyrefly, which is not in pre-production alpha, and is also Rust: https://pyrefly.org/ https://pyrefly.org/ Is there a good reason to avoid using Pyrefly?

jolux 1y ago
I believe Pyrefly is stricter, so it may be a better choice for new projects but harder to integrate into existing ones without type-checking.
- denis- 1y ago
  I have a medium-sized codebase that is all green when running mypy with the strictest configuration possible. Pyrefly spits put around 200 errors for the same codebase. Most errors are related to SQLAlchemy.
  - rhaps0dy 1y ago
    I mean, sqlalchemy until very recently needed a mypy plugin to type correctly (https://docs.sqlalchemy.org/en/20/orm/extensions/mypy.html https://docs.sqlalchemy.org/en/20/orm/extensions/mypy.html), which was just deprecated in 2.0.0. Perhaps you should do the upgrade (https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html#orm-declarative-models https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html...) and try again?
  - samwgoldman 1y ago
    (Pyrefly dev here) Thanks for trying it out! If you have any feedback or bug reports, please don't hesitate to file issues on GitHub or find us on Discord. We have some open issues for SQLAlchemy (like [1]). I'm definitely curious to hear if there are any gaps from your perspective, having an already strictly-typed codebase. 1. https://github.com/facebook/pyrefly/issues/954 https://github.com/facebook/pyrefly/issues/954
diggan 1y ago
> Is there a good reason to avoid using Pyrefly? Wouldn't the other way around be easier for finding good tools? Figure out what matters to you, inspect if the project fulfills those needs and then go with it after making sure it works well for you. Regardless, a comparison between the two was posted to HN not too long time ago: https://news.ycombinator.com/item?id=44107655 https://news.ycombinator.com/item?id=44107655