I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.
Announcing the Beta release of ty
21–30 of 181 posts
Re: Announcing the Beta release of ty
#22I still don’t understand how a single language can have multiple (what is it now, half a dozen?) different type checkers, all with different behaviour.
Do library authors have to test against every type checker to ensure maximum compatibility? Do application developers need to limit their use of libraries to ones that support their particular choice of type checker?
Re: Announcing the Beta release of ty
#23How conformant is this, compared to e.g. mypy?
FWIW MyPy is not very conformant: https://htmlpreview.github.io/?https://github.com/python/typ...
Re: Announcing the Beta release of ty
#24Too bad they did not benchmark Zuban, which is also promising. Also, it's also too bad we have three competing fast LSP/typechecker projects now We had zero 1 year ago.
The guy behind Zuban should've put his project out the in open way earlier. I'd love to see both projects succeed, but in reality it should become one.
Re: Announcing the Beta release of ty
#25I still don’t understand how a single language can have multiple (what is it now, half a dozen?) different type checkers, all with different behaviour. Do library authors have to test against every type checker to ensure maximum compatibility? Do application developers need to limit their use of libraries to ones that support their particular choice of type checker?
You’re talking about a duck typed language with optional type annotations. I love python but that’s a combination that should explain a bit why there are so many different implementations.
Re: Announcing the Beta release of ty
#26I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.
Yeah their work thus far has been an incredible public service to the Python community.
Re: Announcing the Beta release of ty
#27I still don’t understand how a single language can have multiple (what is it now, half a dozen?) different type checkers, all with different behaviour. Do library authors have to test against every type checker to ensure maximum compatibility? Do application developers need to limit their use of libraries to ones that support their particular choice of type checker?
> Do library authors have to test against every type checker to ensure maximum compatibility?
Yes, but in practice, the ecosystem mostly tests against mypy. pyright has been making some inroads, mostly because it backs the diagnostics of the default VS Code Python extension.
> Do application developers need to limit their use of libraries to ones that support their particular choice of type checker?
You can provide your own type stubs instead of using the library's built-in types or existing stubs.
Re: Announcing the Beta release of ty
#28Hopefully it gets added to this comparison: https://htmlpreview.github.io/?https://github.com/python/typ... If that table is anything to go by, Pyright is not to be underestimated. I have briefly tried ty (LSP) in Emacs and it seems to work well so far. The only questionable thing I've encountered is that when the signature of a method is shown, the type annotations of some parameters seem to be presented in a partic…
Pyright has been great. But it’s slow. Speed of a LSP does matter for UX. Excited to see how much ty improves on this.
Re: Announcing the Beta release of ty
#29Without digging too deep- what is the Django story?
Django does a bunch of magic which is challenging for the type checkers to handle well.
Re: Announcing the Beta release of ty
#30well, this is where being pedantic bites me in the a* again. Our codebase has been mostly pyright-focused, with many very specific `pyright: ignore[...]` pragmas. Now it would be great if ty (pyrefly has an option!) could also ignore those lines. There's not _that_ many of them, but .... it's a pain.