- Hopefully 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 particularly verbose form compared to what I'm used to - maybe they're technically correct but it can be bit much to look at.
Anyway, odds are pretty good that ty is what I will end up using long-term, so thanks and congrats on releasing the first beta!
- I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.
- Thanks Astral team! We use Pydantic heavily, and it looks like first class support from Ty is slated for the stable release, we'd love to try it.
While we wait... what's everyone's type checking setup? We run both Pyright and Mypy... they catch different errors so we've kept both, but it feels redundant.
https://htmlpreview.github.io/?https://github.com/python/typ... suggests that Pyright is a superset, which hasn't matched our experience.
Though our analysis was ~2 years ago. Anyone with a large Python codebase successfully consolidated to just Pyright?
- The title of this story should be "Announcing the Beta release of ty". A lot of people have been waiting for the beta specifically.
I've been using Pyrefly and loving it compared to Pyright, but they recently shipped some updates with crash bugs that forced me to pin to a previous version, which is annoying. Unfortunately my first impression of ty isn't great either. Trying to install the ty extension on the current version of Cursor says "Can't install 'astral-sh.ty' extension because it is not compatible with the current version of Cursor (version 2.2.20, VSCode version 1.105.1)."
- I 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 guys are a godsend to the python tooling world. I’ve been far more excited about the impact rust is having on the software world than that of AI, and your work is a big part of that. While I have not seen any real net productivity gains from AI in mine or my juniors work, I’ve definitely seen real gains from using your tooling!
In fact as Jetbrains has been spending years chasing various rabbits including AI, instead of substantially improving or fixing PyCharm, without you steadily replacing/repairing big chunks of Pycharms functionality I would be miserable. If it came down to it, we would happily pay a reasonable license fee to use your tools as long as they stayed free for non-commercial usage.
by collinmcnulty
0 subcomment
- I am so pleased by ty’s stance that I should not have to add annotations to satisfy the type checker. I ripped out last type checker out because it was constantly nagging us about technicalities, but ty immediately found issues where we annotated that a duct was an acceptable input, but actually doing so would break things.
- Very excited to see this. I thought that speed does not matter much for python tooling, but then I tried uv, and realized that I was wrong. The experience is just better. Looking forward to see more high performance quality tooling for Python.
- That's great news!
TIL that ty is also a language server, which means it replaces not only mypy, but also Pyright in Neovim/VSCode.
- well, 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.
- Wow, even if it wasn't so fast, I'd be tempted to use this solely due to their support of intersection (A & B) types! This is a sore omission from the standard python typing system.
by 0cf8612b2e1e
2 subcomments
- Without digging too deep- what is the Django story?
Django does a bunch of magic which is challenging for the type checkers to handle well.
- Slight tangent
I recently viewed tutorials on uv and ruff from Corey Schafer on youtube which were excellent
Hope to make these tools part of my defaults
Look forward a similar overview by Corey on ty :)
Curious ..is there any backstory to these library names?
- Very exciting! I guess I'll have to wait for Django and Pydantic support to migrate to it on Zulip, but type checking was the last major linter that's still slow in Python.
- Too 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.
by Perepiska
1 subcomments
- So I've decided to give it a try.
Open installation instructions and went thru "easy install with uvx" / "get and run our sgell script" until get "pip install ty".
I do not want use other tools so I started it in pet project directory as "ty check". Is shows me progressbar and "98/99 files" then hang.
I restarted it and it hung on "68/99" and started using 100% of cpu core. I waited for 15 min and killed it.
Try to get more information about current file but there is no verbose mode but colorful "ty --help" output.
Lets wait for a year then try again.
Edit: +"then try again"
by Atomic_Torrfisk
1 subcomments
- Serious question, Do we need another type checker in Python?
I've never really felt the existing options were lacking for our use case. Completely fair game if this was just a passion project, but at this point at best this feels like noise, at worst some overzealous developer is going to implement this in my teams pipeline and waste time. Waste his time because the existing type checker did the job and there was not reason to change it, and waste our time because they will likely change (probably tighten) the existing behavior and waste our time while we adapt our habits to it.
- Displaying inferred types inline is a killer feature (inspired from rust lang server?). It was a pleasant surprise!
It's fast too as promised.
However, it doesn't work well with TypedDicts and that's a show-stopper for us. Hoping to see that support soon.
by petesergeant
2 subcomments
- Python programmers are crying out for types it seems. It’s a shame the Python foundation haven’t blessed a spec. Better to get everyone working on a single slightly imperfect standard than a morass or differing ideas.
- I was underwhelmed by uv as a tool when it was announced, and when I started using it. For context, I'm a C++ developer who occasionally has to dip into python-land for scripts and tooling. I set up a new workstation about 6 months ago and decided I'd just use pip + venv again, and honestly I lasted 2 weeks before installing UV again. It's one of those tools that... doesn't really do much except _what you wanted the original tool to do_, and I'm hoping that Ty has the same effect.
by lucas_membrane
0 subcomment
- I just found out that if one is developing a wxPython app, this:
menuFont = wx.Font(12, wx.DEFAULT, wx.NORMAL, wx.NORMAL) # 12pt font
Will be flagged as an error by ty, wx.DEFAULT and wx.NORMAL being some kind of wxPython place holder that wxPython can interpret into a value later on, not a value just yet. Can you get past that kind of late binding?
- Beautiful acknowledgment list, and congratulations on the beta release!
- is there anything like `uv` available for ruby? going from python and typescript where I can use uv and bun, it feels like ruby is stuck in the past :(
by superlopuh
1 subcomments
- We've been relying on TypeForm (an experimental feature in Pyright) in xDSL. Since there are some Astral members commenting here: are there any plans to support TypeForm any time soon? It seems like you already have some features that go beyond the Python type spec, so I feel like there may be hope
- Super excited about this generally ok satisfied with pyright but so I was with conda before uv or black before ruff.
- How conformant is this, compared to e.g. mypy?
- Django support will be a game changer on top of the game changer ty is!
- Jesus, how long will we need this shite? Can't someone from MS fix this already?
Or is it possible for Astral to implement fully fledged Python extension so you don't have to use Microsoft crap that includes proprietary pylance?
```
It's recommended to disable the language server from the Python extension to avoid running two Python language servers by adding the following setting to your settings.json:
{
"python.languageServer": "None"
}
```
- I was reading the list of their offerings in the footer and for a second was very excited by the 5th item:
> RUFF 0.14.9
> UV 0.9.18
> TY 0.0.2
> PYX Beta
> GITHUB
- rust again? ill skip
- Is there any study that shows that typing in Python improves code quality and reduce runtime issues?
- Not impressed because when tried ruff, and discovered that it doesn't replace (basic) pylint check https://github.com/astral-sh/ruff/issues/970 so we have ruff then pylint (and looking at the number of awaiting PR of ruff feels bad)
- The codebase has none of the rust code. In fact even the python code in the code base is mostly just scripts for updating version tags and etc...
Seems like the code isn't actually open source which to me is a bit concerning. At the very least, if ya'll want to release it like this please be clear that you're not open source. The MIT license in the repo gives the wrong impression.
Hacker News