Scala 3: exists, https://docs.scala-lang.org/scala3/book/scala-features.html
Developers: mypy, pyright, pyrefly, ty, pypy, nogil, faster-python, sub-interpreters, free-threading, asyncio, ...
An Update on Pytype
31–40 of 70 posts
Re: An Update on Pytype
#32ex-pytype dev here - we knew this was coming and it's definitely the right thing to do, but it's still a little sad to see the end of an era. in particular, pytype's ability to do flow-based analysis across function boundaries (type checking calls to unannotated functions by symbolically executing the function body with the types of the call arguments) has not been implemented by any of the other checkers (again for…
> while I agree that bytecode-based analysis has its drawbacks
abstract interpretation of the bytecode like y'all were doing is the only way to robustly do type inference in python.
> https://github.com/google/pycnite
there's also https://github.com/MatthieuDartiailh/bytecode which is a good collection
Re: An Update on Pytype
#33ex-pytype dev here - we knew this was coming and it's definitely the right thing to do, but it's still a little sad to see the end of an era. in particular, pytype's ability to do flow-based analysis across function boundaries (type checking calls to unannotated functions by symbolically executing the function body with the types of the call arguments) has not been implemented by any of the other checkers (again for…
> while I agree that bytecode-based analysis has its drawbacks abstract interpretation of the bytecode like y'all were doing is the only way to robustly do type inference in python. > https://github.com/google/pycnite there's also https://github.com/MatthieuDartiailh/bytecode which is a good collection
yeah, that's a really nice project too!
Re: An Update on Pytype
#34Earlier quoted context omitted.
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/ Is there a good reason to avoid using Pyrefly?
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.
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.
Re: An Update on Pytype
#35Earlier quoted context omitted.
Is ty more mature than pyright or mypy? I'm currently using pyright, but I'm going to migrate once ty and its vscode extension are given the "production ready" greenlight.
at this stage I get very few false positives and it's so much easier to configure and use than pyright
ty still doesn't understand match + typing.assert_never pattern, last barrier for me to switching.
Re: An Update on Pytype
#36I 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/
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 ], which I suspect is the real reason for the discontinuation.
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.
Re: An Update on Pytype
#37tl;dr please use pyright instead
Re: An Update on Pytype
#38I 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/
I'm personally just staying away from startups anywhere in my dependencies.
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.
Re: An Update on Pytype
#39DAE GOole killing another project?!!! (Apparently maintaining something completely free of charge for 13 years is not enough for online cannibals)
Re: An Update on Pytype
#40Scala 3: exists, https://docs.scala-lang.org/scala3/book/scala-features.html Developers: mypy, pyright, pyrefly, ty, pypy, nogil, faster-python, sub-interpreters, free-threading, asyncio, ...
This would have been a fair point had Scala 3 supported Python's packages and was compatible with Python's tooling. At the very least until Mojo is mature and open-sourced, there are simply no alternatives to pouring time and effort into making Python a better language.