How about we just stop creating non type safe languages. Would save everyone so much hassle.
[bring on the downvotes]
Ty: A fast Python type checker and language server
111–120 of 296 posts
Re: Ty: A fast Python type checker and language server
#112:wave: Looks like you found the not-so-secret repository we're using to prepare for a broader announcement :) Please be aware this is pre-alpha software. The current version is 0.0.0a6 and the releases so far are all in service of validating our release process. We're excited to get this in people's hands, but want to set the expectation that we still have a lot of work left to do before this is production ready. Sta…
Pointlessmy anal; but 0.0.0a6 is very strongly indicative of the sixth alpha release. Pre-alpha are much better as .dev releases.
Re: Ty: A fast Python type checker and language server
#113Curious why so many people want to implement type checkers for python? What problems are being solved that aren't covered already?
1. complete type checking
in python eco system you have linters like ruff which do hardly any type checking and type checkers like mypy which do try to approach complete type checking, but still are absurdly full of holes
2. speed
any of the "established" type checkers either are supper slow (e.g. mypy) so you only run it like once before commit instead of "life" or do fail to properly type check so many things that if you have a requirement for "adequate static code analysis" they reliably fail that requirement (which might result in a legal liability, but even if not is supper bad for reliable code and long term maintenance)
also probably priorities are switched with 1st speed then closing holes as the later part is really hard due to how a mess python typing is (but in many code bases most code won't run into this holes so it's okay, well except if you idk. use pyalchemy as "ORM" subclassing base model (just don't terrible idea)).
Re: Ty: A fast Python type checker and language server
#114Just compared the time to check on a fairly large project: - mypy (warm cache) 18s - ty: 0.5s (and found 3500 errors) They've done it again.
Great, but how does it compare to Pyright on the utility / performance curve? Pyright is mature and already very fast. https://github.com/microsoft/pyright
Pyright is incredibly slow in my experience, I've seen it take over a minute on complex codebases
Re: Ty: A fast Python type checker and language server
#115:wave: Looks like you found the not-so-secret repository we're using to prepare for a broader announcement :) Please be aware this is pre-alpha software. The current version is 0.0.0a6 and the releases so far are all in service of validating our release process. We're excited to get this in people's hands, but want to set the expectation that we still have a lot of work left to do before this is production ready. Sta…
Pointlessmy anal; but 0.0.0a6 is very strongly indicative of the sixth alpha release. Pre-alpha are much better as .dev releases.
> Pre-alpha are much better as .dev releases.
No, they are correctly using semantic versioning to indicate pre-alpha releases. https://github.com/astral-sh/ty/releases https://semver.org/
Re: Ty: A fast Python type checker and language server
#116Earlier quoted context omitted.
Pointlessmy anal; but 0.0.0a6 is very strongly indicative of the sixth alpha release. Pre-alpha are much better as .dev releases.
> Pre-alpha are much better as .dev releases. No, they are correctly using semantic versioning to indicate pre-alpha releases. https://github.com/astral-sh/ty/releases https://semver.org/
Python doesn’t use plain semver: https://peps.python.org/pep-0440/
Re: Ty: A fast Python type checker and language server
#117:wave: Looks like you found the not-so-secret repository we're using to prepare for a broader announcement :) Please be aware this is pre-alpha software. The current version is 0.0.0a6 and the releases so far are all in service of validating our release process. We're excited to get this in people's hands, but want to set the expectation that we still have a lot of work left to do before this is production ready. Sta…
If you can say - are there any thoughts about implementing plugins / extension capabilities to keep type checking working even with libraries that aren't otherwise typecheckable? (where "not otherwise typecheckable" means types that can't be expressed with stubs - e.g., Django, dataclasses pre-PEP-681, pytest fixtures, etc.)
I also asked this question here: https://github.com/astral-sh/ruff/discussions/15149#discussi....
Re: Ty: A fast Python type checker and language server
#118uv is an incredible tool ; ty will be also. It's insanely fast
For now, I have some false negative warnings :
'global' variables are flagged as undefined `int:unresolved-reference: Name ... used when not defined` (yeah, it's bad, I know)
f(*args) flagged as missing arguments `lint:missing-argument: No arguments provided for required parameters ...`
Re: Ty: A fast Python type checker and language server
#119Interesting to see astral come out with this right around facebook’s release of “Pyrefly, a faster Python type checker written in Rust”. Not making any sort of ethical statement, just interesting that rust keeps eating the python and JS tooling worlds.
language tooling is a sweet spot for rust, for sure.
Re: Ty: A fast Python type checker and language server
#120Interesting to see astral come out with this right around facebook’s release of “Pyrefly, a faster Python type checker written in Rust”. Not making any sort of ethical statement, just interesting that rust keeps eating the python and JS tooling worlds.
Yeah.. Have either of the ty / pyrefly teams reached out to the other? I feel like the community does not really need two fast python type checkers.
(However, vc-backed astral probably need control over theirs to keep monetization options open, and Facebook probably need control over theirs so it can be targeted at Facebook's internal cool-but-non-standard python habits... Sigh.
Why do we have nice things? Money. Why can't we have nice things? Also money.)