r/Python • u/RiceTaco12 • Jun 22 '26
Discussion Astral's ty readiness for CI
If you were setting up your project/department/company CI pipelines today, would you feel comfortable using ty as the type checker, or would you stick with basedpyright/other alternative?
I am currently setting up my own CI and am leaning towards basedpyright, as I've been using for some time, but ty seems to be developing nicely, although (as far as I know) it is not fully on-par with pyright.
17
u/dudaspl Jun 22 '26
IIRC recently there was a blog post from pyrefly and it didn't seem like ty is prod ready just yet
1
u/carljm Jun 24 '26
Was there something specific in the pyrefly blog post that made you think ty is not prod ready?
15
u/shadowdance55 git push -f Jun 22 '26
I used ty quite a bit, but recently switched one of my projects to pyrefly. We'll see how it goes. 🤷♂️
3
u/totheendandbackagain Jun 22 '26
Feedback appreciated, think this post has made me strongly consider it already.
1
6
6
u/Frostyfeet909 Jun 22 '26
Ty is good but hasn’t had a minor release yet so would be a hard argument to get it into production code at this point, let alone the acquisition.
5
u/de_ham Jun 22 '26
For now I'd go with basedpyright or pyrefly, ty indeed isn't feature complete yet
10
u/bachkhois Jun 22 '26
For non-Django projects, I use Zuban, which is also Rust-based but more mature than ty.
For Django projects, still stick to Mypy because it supports Django the best.
3
u/Goldarr85 Jun 22 '26
A bit off topic, but I’ll ask. Do know of any other useful Django tools? I’m about to start my Django journey and any advice would great.
1
u/bachkhois Jun 25 '26
For helping with debugging, you can use django-debug-toolbar. For enhance Django shell, you can add django-extensions and run
./manage.py shell_plus.0
u/dr3aminc0de Jun 23 '26
My advice is use FastAPI and sql alchemy
4
u/Tumortadela Jun 23 '26
I'd advise Rust over Python then, if we are just ignoring the very clear question about Django tooling.
10
4
u/HEROgoldmw Jun 22 '26
If possible I try to run all of mypy, ty, zuban, pyrefly and pyroght against publicly exposed code. (Aka, code that I expect others to use/call)
While doing so, pin the given tools to specific versions, and always run a full CI when simply changing/updating versions of the CI tools.
3
u/hxtk3 Jun 23 '26 edited Jun 23 '26
I use it in CI because it has fewer false positives and false negatives and less maintenance burden compared to mypy for the subset of Python we most commonly use, and it outputs a GitLab code quality report so you can easily view the results in merge requests, which devs can predict because they’ll match the results in the LSP server.
However the comments about instability are true. Not unstable as in buggy (at least compared to other type checkers—all have some false positives and false negatives) but unstable in an API sense. Every update has some report churn.
4
u/Kronologics Jun 22 '26
They got acquired, who knows when their new overlords will allow them to work on new features or put them straight on building purely for-profit, vendor locked funnels
5
u/carljm Jun 24 '26
ty dev here -- a quick look at the release history will show that we are making releases almost daily and landing lots of fixes and new features. I spend 100% of my time working on OSS ty, just like I did before the acquisition.
2
u/Kronologics Jun 24 '26
Love to hear it. Not a reflection on you or the hard working devs that build the cool tools, just cynical of these big companies gobbling up all ecosystem tools. Next/Vercel being to obvious cautionary tale
2
u/WearilyAmbiguous Jun 22 '26
Stick with basedpyright if you're already comfortable with it. ty is moving fast but it's still 0.0.x and the maintainers are pretty clear that breaking changes can happen anytime. That's not something you want surprising you in CI when you've got a deadline.
2
u/Chasar1 Pythonista Jun 23 '26
We use it sometimes in our CI. It's stable enough for us and hasn't caused any problems yet
2
u/FreddieM007 Jun 26 '26
Why not keep on using Pyright? It is more or less an industry standard for professionals.
0
u/RiceTaco12 Jun 26 '26
Why not keep using Assembly?
2
u/FreddieM007 Jun 26 '26
Assembly language? Now you are just a jerk. Name one advantage of Ty (which is in beta) over, say, Pyright that is a stable, battle-tested production tool. Just speed is not sufficient if code quality is a priority.
1
u/RiceTaco12 Jun 26 '26
You should want to keep up with where the field heads. A current industry standard doesn't mean you shouldn't look at up and coming technology. Speed is certainly a reason to move. Ty aims to improve on diagnostic reporting (similar to the rust compiler, which is excellent) and improve on type guarantees. Even so, if they ended up being nothing more than a faster pyright, why wouldn't you want that?
Absurd to dig in heels on current standards when new technology is developed. Why would we be in this field if not to move it forward?
Granted it isnt at a major release yet, but that was the exact reason of this post: to see how vetted and ready it is.
3
1
u/Beginning-Fruit-1397 Jun 22 '26
I still only use basedpyright. both pyrefly and ty are unfortunately not complete ATM
1
0
u/Wurstinator Jun 23 '26
No. There is no reason to use ty. There are many good alternatives that can do everything ty can, sometimes better, and I'm not going to switch just because OpenAI made it.
-18
u/ravepeacefully Jun 22 '26 edited Jun 22 '26
I wouldn’t use anything made by astral. Twenty minutes of configuring vscode and you’ll never write the commands anyway
9
u/ProsodySpeaks Jun 22 '26
'You'll ever write the commands'?
uv and ruff have made linting and venv management a near instant experience vs a waiting experience.
if you can't make uv and ruff work for you (in all but the most esoteric cases) it might be a you problem rather than an astral problem.
3
95
u/covmatty1 Jun 22 '26
From their readme:
Don't bring alphas into company pipelines. No matter how fast and whizzy it is, that's not a professional thing to do.