9 ms·

Announcing the Beta release of ty

854 points by gavide 10mo ago

Ch00k 10mo ago
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.
- BiteCode_dev 10mo ago
  Having fast and reliable code indexing, enable good "go to definition", completion and auto import is actually very exciting. Pyright/pylance were a boon because they were the first non-pycharm good implementation. But they still have rough edges and will fail from time to time, not to mention the latency.
modeless 10mo ago
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)."
- charliermarsh 10mo ago
  If there's anything else accompanying the error, do you mind filing an issue? I've been using the ty extension with Cursor for weeks and am having trouble reproducing right now.
  - modeless 10mo ago
    That's the full error. It shows up in a dialog box when I press the install button. I'm on macOS, connected with the Anysphere Remote SSH extension to a Linux machine. If I choose "install previous version" I am able to install the pre-release version from 12 hours ago without issue. Then on the extension page I get a button labeled "Switch to Release Version" and when I press it I get an error that says "Can't install release version of 'ty' extension because it has no release version." Filed a GitHub issue with these details. In the meantime, the previous version appears to be working well! I like that it worked without any configuration. The Pyrefly extension needed a config tweak to work.
    - _carljm 10mo ago
      I can reproduce this; we're looking into it.
    - _carljm 10mo ago
      https://forum.cursor.com/t/newly-published-extensions-appear-slower-on-cursor-than-vscode/39028/3 https://forum.cursor.com/t/newly-published-extensions-appear... suggests that there's some kind of delayed daily update for new VSCode extension versions to become available to Cursor? It seems likely that's what is happening here, since ty-vscode 0.0.2 was only published an hour or two ago.
      - modeless 10mo ago
        Oh, huh, and since there's no previous release version it just fails to install completely? That's unfortunate.
- ocamoss 10mo ago
  (pyrefly maintainer here) If you haven't already, please file an issue for that crash on the [Pyrefly repo](https://github.com/facebook/pyrefly https://github.com/facebook/pyrefly) as well :)
- chombier 10mo ago
  Apart from installation problems/crash issues, do you have some feedback about type checking with ty vs. pyrefly? Which is stricter, soundness issues, etc? Both are rust/open-source/new/fast so it's difficult to understand why I should choose one over the other.
frou_dh 10mo ago
Hopefully it gets added to this comparison: https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html 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!
- _carljm 10mo ago
  We'll be adding ourselves to that table soon. We'll have some work to catch up with pyright on conformance, but that's what the time between now and stable release is for.
- IshKebab 10mo ago
  Pyright is really really good. Anyone that doubts that 10x engineers exist, just go and look at Eric Traut. He's pretty much written it single handedly. Absolute machine. Mypy is trash. Nice to have a table to point to to prove it.
  - buibuibui 10mo ago
    Oh my, I just looked him up. He is the developer of Virtual Game Station - a PS1 emulator that I used in the past to play PS Isos on my Windows ME PC! What a legend.
    - jimmydoe 10mo ago
      Wat Unbelievable
  - davidhalter 10mo ago
    Mypy is not trash at all. It is still the most precise type checker, supports a lot of complicated cases and has plugins that make a lot of things more type safe. I believe Mypy is severely underrated and a lot of people believe that it's not as good as Pyright because of the conformance tests. The problem is that the conformance tests were mostly written by Eric Traut, so there's a natural bias towards specifying what Pyright does well. There's a lot of things Mypy does really well that should probably be implemented in Pyright.
maxloh 10mo ago
How conformant is this, compared to e.g. mypy?
- danudey 10mo ago
  FWIW MyPy is not very conformant: https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html https://htmlpreview.github.io/?https://github.com/python/typ...
- the-wumpus 10mo ago
  It's not great, but in this very thread there's a person from the conformance team that says that it shouldn't sway your choice too much. https://htmlpreview.github.io/?https://github.com/SimonSchick/typing/blob/feat/add-ty/conformance/results/results.html https://htmlpreview.github.io/?https://github.com/SimonSchic...
tabbott 10mo ago
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.
almanael 10mo ago
Not impressed because when tried ruff, and discovered that it doesn't replace (basic) pylint check https://github.com/astral-sh/ruff/issues/970 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)
- zanie 10mo ago
  As noted in the linked issue > At time of writing, many of the remaining rules require type inference and/or multi-file analysis, and aren't ready to be implemented in Ruff. ty is actually a big step in this direction as it provides multi-file analysis and type inference. (I work at Astral)
  - int_19h 10mo ago
    Are you guys planning to tackle Python debugging next? pydevd could really use a fast native rewrite targeting modern Python.
- caidan 10mo ago
  Ruff is incredible, replacing a mountain of tools and rules with a single extremely fast linter/formatter. Given that it is updated and improved frequently, I’m curious if you have tried it recently, and if so what pylint rules are you using that it doesn’t cover?
f311a 10mo ago
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.
- iamdanieljohns 10mo 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.
  - arthur-st 10mo ago
    For real. I consider myself to be “into Python typing,” and yet I had no knowledge of Zuban before the parent comment and a very faint memory of Jedi.
  - davidhalter 10mo ago
    Zuban maybe doesn't succeed in terms of the amount of users, but it's nearly finished, supports the full Python type system (I'm in the process of completing the conformance tests), has support for Django and LSP support is also pretty much complete. So in a technical way it did already succeed. It might not be used as much, but to be honest I think that's fine. I'm not a big VC-funded company and just hope to be able to serve the users it has. There's space for multiple tools in this area and it's probably good to have multiple type checkers in the Python world to avoid the typical VC rug pull.
    - the-wumpus 10mo ago
      Zuban continues to have "not great" diagnostics like the rest of the python type checkers, where ty has "rust inspired" diagnostics that are extremely helpful. It's a shame to hear that the current state is considered "nearly finished".
      - davidhalter 10mo ago
        Have you tried `--pretty`? That is more of a Rust style. Most type checker report the short version, but have longer versions of the issues. IMO that's a good choice, but opinions might differ.
Svoka 10mo ago
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.
sails01 10mo ago
Is there any study that shows that typing in Python improves code quality and reduce runtime issues?
- hexo 10mo ago
  Well, it's just a documentation suggestion for user. Having for me about same value as if it was written in pydoc. I'd really love to see such study as well
  - sails01 10mo ago
    Agree, we already had a solution documenting types in docstring. In my case they just add noise when reading code and make it more difficult to review
- bmitc 10mo ago
  That's equivalent to asking if there are benefits of static typing.
  - sails01 10mo ago
    Not quite, static typing is used at runtime, python type annotations are not
    - amethyst 10mo ago
      tools like dataclasses and pydantic would like to have a word...
    - dragonwriter 10mo ago
      > Not quite, static typing is used at runtime, python type annotations are not No, static typing is usually used AOT (most frequently at compile time), not usually at runtime (types may or may not exist at runtime; they don't in Haskell, for instance.) Python type checking is also AOT, but (unlike where it is inextricably tied to compilation because types are not only checked but used for code generation) it is optional to actually do that step. Python type annotations exist and are sometimes used at runtime, but not usually at that point for type checking in the usual sense.
Zababa 10mo ago
Beautiful acknowledgment list, and congratulations on the beta release!
klysm 10mo ago
I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.
- tabbott 10mo ago
  Yeah their work thus far has been an incredible public service to the Python community.
- amanzi 10mo ago
  "pyx" is their first commercial offering: https://astral.sh/pyx https://astral.sh/pyx I agree though. Hope this is successful and they keep building awesome open-source tools.
  - clircle 10mo ago
    Why the “y” look so wrong in the special font.
  - jbmsf 10mo ago
    We're paying for pyx. Wouldn't have if we didn't enjoy enjoy uv and ruff. It's definitely a narrow path for them to tread. Feels like the best case is something like Hashicorp, great until the founders don't want to do it anymore.
    - embedding-shape 10mo ago
      > Feels like the best case is something like Hashicorp Wow, that's probably my go-to case of things going south, not "best case scenario". They sold to IBM, a famous graveyard for software, and on the way there changed from FOSS licensing to their own proprietary ones for software the community started to rely on.
      - jbmsf 10mo ago
        You're not wrong, but a) most of the badness happened after the founders checked out and b) it's hard to find examples of developer tool companies doing better.
pansa2 10mo ago
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?
- WD-42 10mo ago
  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.
  - MangoToupe 10mo ago
    It doesn't. Either the optional type annotations have precise semantics or they don't.
    - dwattttt 10mo ago
      What should a type checker say about this code? x = [] x.append(1) x[0] = "new" x[0] + "oops" It's optionally typed, but I would credit both "type checks correctly" and "can't assign 'new' over a number" as valid type checker results.
      - MangoToupe 10mo ago
        It depends on the semantics the language specifies. Whether or not the annotations are optional is irrelevant. Either way, you didn't annotate the code so it's kind of pointless to discuss. Also fwiw python is typed regardless of the annotations; types are not optional in any sense. Unless you're using BCPL or forth or something like that
        dwattttt 10mo ago
        > Either way, you didn't annotate the code so it's kind of pointless to discuss. There are several literals in that code snippet; I could annotate them with their types, and this code would still be exactly as it is. You asked why there are competing type checkers, and the fact that the language is only optionally typed means ambiguity like that example exists, and should be a warning/bug/allowed; choose the type checker that most closely matches the semantics you want to impose.
0cf8612b2e1e 10mo ago
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.
- selcuka 10mo ago
  Ty doesn't support Django yet, and it doesn't have a plugin system, so third party developers can't improve it. If you need Django support, it is better to stick to mypy or pyright for the time being.
  - 0cf8612b2e1e 10mo ago
    Is Django planned? Or always going to be a non first party kind of deal?
    - selcuka 10mo ago
      It is being planned, but there is no timeframe [1]: > We are planning to add dedicated Django support at some point, but it's not on our short-term roadmap [1] https://github.com/astral-sh/ruff/pull/21308#issuecomment-3503018889 https://github.com/astral-sh/ruff/pull/21308#issuecomment-35...
      - czue 10mo ago
        They say in the docs that they want Django support before the official release.
- davidhalter 10mo ago
  Feel free to use Zuban, it already supports Django models and is way ahead in typing support (and it's probably as fast as Ty).
fkarg 10mo ago
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.
syiblet 10mo ago
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.
- woodruffw 10mo ago
  The ty repo contains the ruff repo[1] as a submodule, where the remainder of the code is. It is indeed open source, the layout is just indirect at the moment because of code-sharing between the tools. [1]: https://github.com/astral-sh/ruff https://github.com/astral-sh/ruff
  - zanie 10mo ago
    This is also documented at https://github.com/astral-sh/ty?tab=readme-ov-file#contributing https://github.com/astral-sh/ty?tab=readme-ov-file#contribut... and https://github.com/astral-sh/ty/blob/main/CONTRIBUTING.md#repository-structure https://github.com/astral-sh/ty/blob/main/CONTRIBUTING.md#re...
- bobthecowboy 10mo ago
  At least as of a couple months ago, `ty` was actually being developed in the `ruff` repo (per an pdocast interview the devs did on Talk Python), so that might be why the `ty` repo looks empty (and pulls in ruff as a git submodule).
- simonw 10mo ago
  I think that's because most of the code for `ty` is tucked away in the `ruff` codebase: https://github.com/astral-sh/ruff/tree/main/crates/ty https://github.com/astral-sh/ruff/tree/main/crates/ty - it's all MIT licensed.
shrumm 10mo ago
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/typing/blob/main/conformance/results/results.html 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?
- hauntsaninja 10mo ago
  Mentioned this in another comment, but the spec conformance suite is not representative of the things users care about (nor is it meant to be). The spec mostly concerns itself with the semantics of annotations, not diagnostics or inference. I don't really recommend using it as the basis for choosing a type checker. (I was on the Python Typing Council and helped put together the spec, the conformance test suite, etc)
- gwking 10mo ago
  I appreciate the even tempered question. I’ve been using mypy since its early days, and when pyright was added to vs code I was forced to reckon with their differences. For the most part I found mypy was able to infer more accurately and flexibly. At various times I had to turn pyright off entirely because of false positives. But perhaps someone else would say that I’m leaning on weaknesses of mypy; I think I’m pretty strict but who knows. And like yourself, mine is a rather dated opinion. It used to be that every mypy release was an event, where I’d have a bunch of new errors to fix, but that lessened over the years. I suspect pyright has caught up a lot but I turned it off again rather recently. For what it’s worth I did give up on cursor mostly because basedpyright was very counterproductive for me. I will say that I’ve seen a lot more vehement trash talking about mypy and gushing about pyright than vice versa for quite a few years. It doesn’t quite add up in my mind.
  - shrumm 10mo ago
collinmcnulty 10mo ago
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.
akdor1154 10mo ago
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.
hexo 10mo ago
rust again? ill skip
numbers 10mo ago
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 :(
- pansa2 10mo ago
  Rv, a new kind of Ruby management tool: https://news.ycombinator.com/item?id=45023730 https://news.ycombinator.com/item?id=45023730
pcwelder 10mo ago
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.
- sharkdp 10mo ago
  We should generally support TypeDicts. Can you go into more details of what is not working for you?
  - pcwelder 10mo ago
``` from anthropic.types import MessageParam data: list[MessageParam] = [{"role": "user", "content": [{"type": "text", "text": ""}]}] ``` This for example works both in mypy and pyright. (Also autocompletion of typedict keys / literals from pylance is missing)
- sharkdp 10mo ago
  Thank you! I reported this as https://github.com/astral-sh/ty/issues/1994 https://github.com/astral-sh/ty/issues/1994 Support for auto-completing TypedDict keys is tracked here: https://github.com/astral-sh/ty/issues/86 https://github.com/astral-sh/ty/issues/86
parham 10mo ago
Django support will be a game changer on top of the game changer ty is!
lysecret 10mo ago
Super excited about this generally ok satisfied with pyright but so I was with conda before uv or black before ruff.
falcor84 10mo ago
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
petesergeant 10mo ago
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.
- ReflectedImage 10mo ago
  Speaking as a Python programmer, no. Using types in a prototyping language is madness. The point is you drop things such as types to enable rapid iteration which enables you to converge to the unknownable business requirements faster. If you want slow development with types, why not Java?
  - philipallstar 10mo ago
    > Using types in a prototyping language is madness. It's not a prototyping language or a scripting language or whatever. It's just a language. And types are useful, especially when you can opt out of type checking when you need to. Most of the time you don't want to be reassigning variables to be different types anyway, even though occasionally an escape hatch is nice.
    - ReflectedImage 10mo ago
      Types are not always useful, they increase the line count per delivered feature by 3x to 4x, which results in a corresponding increase in bugs in the delivered code and an corresponding increase in the overall software development costs. It's very foolish to just use types in all programming projects.
  - solarkraft 10mo ago
    because i want fast development with types.
    - ReflectedImage 10mo ago
      Yeah, but that doesn't exist. Types and fast development are directly opposing goals. This goes all the way back to Lisp vs C in the 1980s with C programs having triple the development time as Lisp programs. To modern day with Turborepo taking 3 months to write in structually typed Go vs 14 months in statically typed Rust.
wiseowise 10mo ago
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" } ```
caidan 10mo ago
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.
- linhns 10mo ago
  Nice to see Pycharm going downhill being mentioned. Nice tool in the past, not much so now.
albert_e 10mo ago
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?
- japhyr 10mo ago
  I believe the've been looking for two-letter names that aren't already taken, and are easy to type. I think I heard that from one of the podcasts that Charlie Marsh was on.
  - benrutter 10mo ago
    Source here for anyone interested[0]. From memory, Ruff was its own thing, (I think named after the bird?) since then they've tried to give projects short letter combinations for consistency and ease of typing (uv, ty, pyx) [0] https://talkpython.fm/episodes/download/520/pyx-the-other-side-of-the-uv-coin-announcing-pyx.mp3 https://talkpython.fm/episodes/download/520/pyx-the-other-si...
    - zanie 10mo ago
      Ruff wasn't named after the bird, we just think it's funny that Charlie didn't know it was a bird. He made up the word :)
      - collinmanderson 10mo ago
        I've always assumed it was something like: ruff - "RUst Formatter". ty - "TYpe checker" uv - "Unified python packaging Versioner"? or "UniVersal python packaging"
        BiteCode_dev 10mo ago
        Also note that R, U and T are one letter away to spell Rust.
superlopuh 10mo ago
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
- dcreager 10mo ago
  Yes, we love TypeForm! We plan to support it as soon as the PEP for it lands. Under the covers, we already support much of what's needed, and use it for some of our special-cased functions like `ty_extensions.is_equivalent_to` [1,2]. TypeForm proper has been lower on the priority list mostly because we have a large enough backlog as it is, and that lets us wait to make sure there aren't any last-minute changes to the syntax. [1] https://github.com/astral-sh/ruff/blob/0bd7a94c2732c232cc1423756e2437d9bce558b1/crates/ty_vendored/ty_extensions/ty_extensions.pyi#L113-L115 https://github.com/astral-sh/ruff/blob/0bd7a94c2732c232cc142... [2] https://github.com/astral-sh/ruff/blob/0bd7a94c2732c232cc1423756e2437d9bce558b1/crates/ty_python_semantic/src/types.rs#L5792 https://github.com/astral-sh/ruff/blob/0bd7a94c2732c232cc142...
maccard 10mo ago
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.
Atomic_Torrfisk 10mo ago
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.
- the-wumpus 10mo ago
  The existing type checkers are slow. That's their reasoning for creating it. The type checking world in python is now reasonably well specified (and the type checkers are beginning to work more similarly), so I would expect (once ty is out of beta) you could replace your type checker with ty and just see a 20x speedup in CI and much much faster IDE diagnostics. If it was going from 3s -> 1s then you'd probably be right, but on my work codebase pyright (which is the faster one!) takes 15 seconds (ty takes 0.8s) and takes a bit for errors to appear in the IDE. This is now fast enough for us (mypy was taking >30s, which was not fast enough), but if the project grew another order of magnitude (which it might) then it would probably be too slow. It's the same reason ruff is great, linting the codebase is so so fast.
Perepiska 10mo ago
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"
- dcreager 10mo ago
  There was a hang/performance bug [1, 2] that was reported just after the beta release, which we've since fixed [3]. You might try seeing if we get through your entire project now? (And as an aside, there _is_ a verbose mode: if you add `-vv` you'll get DEBUG-level log messages printing out the name of each file as we start to check it, and you can set TY_MAX_PARALLELISM=1 in your env to make it very clear which file is causing the hang. That's how we debug these kinds of issues when they're reported to us.) [1] https://github.com/astral-sh/ty/issues/1968 https://github.com/astral-sh/ty/issues/1968 [2] https://github.com/astral-sh/ty/issues/1993 https://github.com/astral-sh/ty/issues/1993 [3] https://github.com/astral-sh/ruff/pull/22030 https://github.com/astral-sh/ruff/pull/22030
lucas_membrane 10mo ago
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?

854 points by gavide 10mo ago

Ch00k 10mo ago

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.

BiteCode_dev 10mo ago
Having fast and reliable code indexing, enable good "go to definition", completion and auto import is actually very exciting. Pyright/pylance were a boon because they were the first non-pycharm good implementation. But they still have rough edges and will fail from time to time, not to mention the latency.

modeless 10mo ago

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)."

charliermarsh 10mo ago
If there's anything else accompanying the error, do you mind filing an issue? I've been using the ty extension with Cursor for weeks and am having trouble reproducing right now.
- modeless 10mo ago
  That's the full error. It shows up in a dialog box when I press the install button. I'm on macOS, connected with the Anysphere Remote SSH extension to a Linux machine. If I choose "install previous version" I am able to install the pre-release version from 12 hours ago without issue. Then on the extension page I get a button labeled "Switch to Release Version" and when I press it I get an error that says "Can't install release version of 'ty' extension because it has no release version." Filed a GitHub issue with these details. In the meantime, the previous version appears to be working well! I like that it worked without any configuration. The Pyrefly extension needed a config tweak to work.
  - _carljm 10mo ago
    I can reproduce this; we're looking into it.
  - _carljm 10mo ago
    https://forum.cursor.com/t/newly-published-extensions-appear-slower-on-cursor-than-vscode/39028/3 https://forum.cursor.com/t/newly-published-extensions-appear... suggests that there's some kind of delayed daily update for new VSCode extension versions to become available to Cursor? It seems likely that's what is happening here, since ty-vscode 0.0.2 was only published an hour or two ago.
    - modeless 10mo ago
      Oh, huh, and since there's no previous release version it just fails to install completely? That's unfortunate.
ocamoss 10mo ago
(pyrefly maintainer here) If you haven't already, please file an issue for that crash on the [Pyrefly repo](https://github.com/facebook/pyrefly https://github.com/facebook/pyrefly) as well :)
chombier 10mo ago
Apart from installation problems/crash issues, do you have some feedback about type checking with ty vs. pyrefly? Which is stricter, soundness issues, etc? Both are rust/open-source/new/fast so it's difficult to understand why I should choose one over the other.

frou_dh 10mo ago

Hopefully it gets added to this comparison: https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html 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!

_carljm 10mo ago
We'll be adding ourselves to that table soon. We'll have some work to catch up with pyright on conformance, but that's what the time between now and stable release is for.
IshKebab 10mo ago
Pyright is really really good. Anyone that doubts that 10x engineers exist, just go and look at Eric Traut. He's pretty much written it single handedly. Absolute machine. Mypy is trash. Nice to have a table to point to to prove it.
- buibuibui 10mo ago
  Oh my, I just looked him up. He is the developer of Virtual Game Station - a PS1 emulator that I used in the past to play PS Isos on my Windows ME PC! What a legend.
  - jimmydoe 10mo ago
    Wat Unbelievable
- davidhalter 10mo ago
  Mypy is not trash at all. It is still the most precise type checker, supports a lot of complicated cases and has plugins that make a lot of things more type safe. I believe Mypy is severely underrated and a lot of people believe that it's not as good as Pyright because of the conformance tests. The problem is that the conformance tests were mostly written by Eric Traut, so there's a natural bias towards specifying what Pyright does well. There's a lot of things Mypy does really well that should probably be implemented in Pyright.

maxloh 10mo ago

How conformant is this, compared to e.g. mypy?

danudey 10mo ago
FWIW MyPy is not very conformant: https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html https://htmlpreview.github.io/?https://github.com/python/typ...
the-wumpus 10mo ago
It's not great, but in this very thread there's a person from the conformance team that says that it shouldn't sway your choice too much. https://htmlpreview.github.io/?https://github.com/SimonSchick/typing/blob/feat/add-ty/conformance/results/results.html https://htmlpreview.github.io/?https://github.com/SimonSchic...

tabbott 10mo ago

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.

almanael 10mo ago

Not impressed because when tried ruff, and discovered that it doesn't replace (basic) pylint check https://github.com/astral-sh/ruff/issues/970 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)

zanie 10mo ago
As noted in the linked issue > At time of writing, many of the remaining rules require type inference and/or multi-file analysis, and aren't ready to be implemented in Ruff. ty is actually a big step in this direction as it provides multi-file analysis and type inference. (I work at Astral)
- int_19h 10mo ago
  Are you guys planning to tackle Python debugging next? pydevd could really use a fast native rewrite targeting modern Python.
caidan 10mo ago
Ruff is incredible, replacing a mountain of tools and rules with a single extremely fast linter/formatter. Given that it is updated and improved frequently, I’m curious if you have tried it recently, and if so what pylint rules are you using that it doesn’t cover?

f311a 10mo ago

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.

iamdanieljohns 10mo 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.
- arthur-st 10mo ago
  For real. I consider myself to be “into Python typing,” and yet I had no knowledge of Zuban before the parent comment and a very faint memory of Jedi.
- davidhalter 10mo ago
  Zuban maybe doesn't succeed in terms of the amount of users, but it's nearly finished, supports the full Python type system (I'm in the process of completing the conformance tests), has support for Django and LSP support is also pretty much complete. So in a technical way it did already succeed. It might not be used as much, but to be honest I think that's fine. I'm not a big VC-funded company and just hope to be able to serve the users it has. There's space for multiple tools in this area and it's probably good to have multiple type checkers in the Python world to avoid the typical VC rug pull.
  - the-wumpus 10mo ago
    Zuban continues to have "not great" diagnostics like the rest of the python type checkers, where ty has "rust inspired" diagnostics that are extremely helpful. It's a shame to hear that the current state is considered "nearly finished".
    - davidhalter 10mo ago
      Have you tried `--pretty`? That is more of a Rust style. Most type checker report the short version, but have longer versions of the issues. IMO that's a good choice, but opinions might differ.

Svoka 10mo ago

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.

sails01 10mo ago

Is there any study that shows that typing in Python improves code quality and reduce runtime issues?

hexo 10mo ago
Well, it's just a documentation suggestion for user. Having for me about same value as if it was written in pydoc. I'd really love to see such study as well
- sails01 10mo ago
  Agree, we already had a solution documenting types in docstring. In my case they just add noise when reading code and make it more difficult to review
bmitc 10mo ago
That's equivalent to asking if there are benefits of static typing.
- sails01 10mo ago
  Not quite, static typing is used at runtime, python type annotations are not
  - amethyst 10mo ago
    tools like dataclasses and pydantic would like to have a word...
  - dragonwriter 10mo ago
    > Not quite, static typing is used at runtime, python type annotations are not No, static typing is usually used AOT (most frequently at compile time), not usually at runtime (types may or may not exist at runtime; they don't in Haskell, for instance.) Python type checking is also AOT, but (unlike where it is inextricably tied to compilation because types are not only checked but used for code generation) it is optional to actually do that step. Python type annotations exist and are sometimes used at runtime, but not usually at that point for type checking in the usual sense.

Zababa 10mo ago

Beautiful acknowledgment list, and congratulations on the beta release!

klysm 10mo ago

I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.

tabbott 10mo ago
Yeah their work thus far has been an incredible public service to the Python community.
amanzi 10mo ago
"pyx" is their first commercial offering: https://astral.sh/pyx https://astral.sh/pyx I agree though. Hope this is successful and they keep building awesome open-source tools.
- clircle 10mo ago
  Why the “y” look so wrong in the special font.
- jbmsf 10mo ago
  We're paying for pyx. Wouldn't have if we didn't enjoy enjoy uv and ruff. It's definitely a narrow path for them to tread. Feels like the best case is something like Hashicorp, great until the founders don't want to do it anymore.
  - embedding-shape 10mo ago
    > Feels like the best case is something like Hashicorp Wow, that's probably my go-to case of things going south, not "best case scenario". They sold to IBM, a famous graveyard for software, and on the way there changed from FOSS licensing to their own proprietary ones for software the community started to rely on.
    - jbmsf 10mo ago
      You're not wrong, but a) most of the badness happened after the founders checked out and b) it's hard to find examples of developer tool companies doing better.

pansa2 10mo ago

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?

WD-42 10mo ago
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.
- MangoToupe 10mo ago
  It doesn't. Either the optional type annotations have precise semantics or they don't.
  - dwattttt 10mo ago
    What should a type checker say about this code? x = [] x.append(1) x[0] = "new" x[0] + "oops" It's optionally typed, but I would credit both "type checks correctly" and "can't assign 'new' over a number" as valid type checker results.
    - MangoToupe 10mo ago
      It depends on the semantics the language specifies. Whether or not the annotations are optional is irrelevant. Either way, you didn't annotate the code so it's kind of pointless to discuss. Also fwiw python is typed regardless of the annotations; types are not optional in any sense. Unless you're using BCPL or forth or something like that
      - dwattttt 10mo ago
        > Either way, you didn't annotate the code so it's kind of pointless to discuss. There are several literals in that code snippet; I could annotate them with their types, and this code would still be exactly as it is. You asked why there are competing type checkers, and the fact that the language is only optionally typed means ambiguity like that example exists, and should be a warning/bug/allowed; choose the type checker that most closely matches the semantics you want to impose.

0cf8612b2e1e 10mo ago

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.

selcuka 10mo ago
Ty doesn't support Django yet, and it doesn't have a plugin system, so third party developers can't improve it. If you need Django support, it is better to stick to mypy or pyright for the time being.
- 0cf8612b2e1e 10mo ago
  Is Django planned? Or always going to be a non first party kind of deal?
  - selcuka 10mo ago
    It is being planned, but there is no timeframe [1]: > We are planning to add dedicated Django support at some point, but it's not on our short-term roadmap [1] https://github.com/astral-sh/ruff/pull/21308#issuecomment-3503018889 https://github.com/astral-sh/ruff/pull/21308#issuecomment-35...
    - czue 10mo ago
      They say in the docs that they want Django support before the official release.
davidhalter 10mo ago
Feel free to use Zuban, it already supports Django models and is way ahead in typing support (and it's probably as fast as Ty).

fkarg 10mo ago

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.

syiblet 10mo ago

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.

woodruffw 10mo ago
The ty repo contains the ruff repo[1] as a submodule, where the remainder of the code is. It is indeed open source, the layout is just indirect at the moment because of code-sharing between the tools. [1]: https://github.com/astral-sh/ruff https://github.com/astral-sh/ruff
- zanie 10mo ago
  This is also documented at https://github.com/astral-sh/ty?tab=readme-ov-file#contributing https://github.com/astral-sh/ty?tab=readme-ov-file#contribut... and https://github.com/astral-sh/ty/blob/main/CONTRIBUTING.md#repository-structure https://github.com/astral-sh/ty/blob/main/CONTRIBUTING.md#re...
bobthecowboy 10mo ago
At least as of a couple months ago, `ty` was actually being developed in the `ruff` repo (per an pdocast interview the devs did on Talk Python), so that might be why the `ty` repo looks empty (and pulls in ruff as a git submodule).
simonw 10mo ago
I think that's because most of the code for `ty` is tucked away in the `ruff` codebase: https://github.com/astral-sh/ruff/tree/main/crates/ty https://github.com/astral-sh/ruff/tree/main/crates/ty - it's all MIT licensed.

shrumm 10mo ago

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/typing/blob/main/conformance/results/results.html 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?

hauntsaninja 10mo ago
Mentioned this in another comment, but the spec conformance suite is not representative of the things users care about (nor is it meant to be). The spec mostly concerns itself with the semantics of annotations, not diagnostics or inference. I don't really recommend using it as the basis for choosing a type checker. (I was on the Python Typing Council and helped put together the spec, the conformance test suite, etc)
gwking 10mo ago
I appreciate the even tempered question. I’ve been using mypy since its early days, and when pyright was added to vs code I was forced to reckon with their differences. For the most part I found mypy was able to infer more accurately and flexibly. At various times I had to turn pyright off entirely because of false positives. But perhaps someone else would say that I’m leaning on weaknesses of mypy; I think I’m pretty strict but who knows. And like yourself, mine is a rather dated opinion. It used to be that every mypy release was an event, where I’d have a bunch of new errors to fix, but that lessened over the years. I suspect pyright has caught up a lot but I turned it off again rather recently. For what it’s worth I did give up on cursor mostly because basedpyright was very counterproductive for me. I will say that I’ve seen a lot more vehement trash talking about mypy and gushing about pyright than vice versa for quite a few years. It doesn’t quite add up in my mind.
- shrumm 10mo ago

collinmcnulty 10mo ago

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.

akdor1154 10mo ago

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.

hexo 10mo ago

rust again? ill skip

numbers 10mo ago

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 :(

pansa2 10mo ago
Rv, a new kind of Ruby management tool: https://news.ycombinator.com/item?id=45023730 https://news.ycombinator.com/item?id=45023730

pcwelder 10mo ago

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.

sharkdp 10mo ago
We should generally support TypeDicts. Can you go into more details of what is not working for you?
- pcwelder 10mo ago
``` from anthropic.types import MessageParam data: list[MessageParam] = [{"role": "user", "content": [{"type": "text", "text": ""}]}] ``` This for example works both in mypy and pyright. (Also autocompletion of typedict keys / literals from pylance is missing)
- sharkdp 10mo ago
  Thank you! I reported this as https://github.com/astral-sh/ty/issues/1994 https://github.com/astral-sh/ty/issues/1994 Support for auto-completing TypedDict keys is tracked here: https://github.com/astral-sh/ty/issues/86 https://github.com/astral-sh/ty/issues/86

parham 10mo ago

Django support will be a game changer on top of the game changer ty is!

lysecret 10mo ago

Super excited about this generally ok satisfied with pyright but so I was with conda before uv or black before ruff.

falcor84 10mo ago

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

petesergeant 10mo ago

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.

ReflectedImage 10mo ago
Speaking as a Python programmer, no. Using types in a prototyping language is madness. The point is you drop things such as types to enable rapid iteration which enables you to converge to the unknownable business requirements faster. If you want slow development with types, why not Java?
- philipallstar 10mo ago
  > Using types in a prototyping language is madness. It's not a prototyping language or a scripting language or whatever. It's just a language. And types are useful, especially when you can opt out of type checking when you need to. Most of the time you don't want to be reassigning variables to be different types anyway, even though occasionally an escape hatch is nice.
  - ReflectedImage 10mo ago
    Types are not always useful, they increase the line count per delivered feature by 3x to 4x, which results in a corresponding increase in bugs in the delivered code and an corresponding increase in the overall software development costs. It's very foolish to just use types in all programming projects.
- solarkraft 10mo ago
  because i want fast development with types.
  - ReflectedImage 10mo ago
    Yeah, but that doesn't exist. Types and fast development are directly opposing goals. This goes all the way back to Lisp vs C in the 1980s with C programs having triple the development time as Lisp programs. To modern day with Turborepo taking 3 months to write in structually typed Go vs 14 months in statically typed Rust.

wiseowise 10mo ago

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" } ```

caidan 10mo ago

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.

linhns 10mo ago
Nice to see Pycharm going downhill being mentioned. Nice tool in the past, not much so now.

albert_e 10mo ago

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?

japhyr 10mo ago
I believe the've been looking for two-letter names that aren't already taken, and are easy to type. I think I heard that from one of the podcasts that Charlie Marsh was on.
- benrutter 10mo ago
  Source here for anyone interested[0]. From memory, Ruff was its own thing, (I think named after the bird?) since then they've tried to give projects short letter combinations for consistency and ease of typing (uv, ty, pyx) [0] https://talkpython.fm/episodes/download/520/pyx-the-other-side-of-the-uv-coin-announcing-pyx.mp3 https://talkpython.fm/episodes/download/520/pyx-the-other-si...
  - zanie 10mo ago
    Ruff wasn't named after the bird, we just think it's funny that Charlie didn't know it was a bird. He made up the word :)
    - collinmanderson 10mo ago
      I've always assumed it was something like: ruff - "RUst Formatter". ty - "TYpe checker" uv - "Unified python packaging Versioner"? or "UniVersal python packaging"
      - BiteCode_dev 10mo ago
        Also note that R, U and T are one letter away to spell Rust.

superlopuh 10mo ago

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

dcreager 10mo ago
Yes, we love TypeForm! We plan to support it as soon as the PEP for it lands. Under the covers, we already support much of what's needed, and use it for some of our special-cased functions like `ty_extensions.is_equivalent_to` [1,2]. TypeForm proper has been lower on the priority list mostly because we have a large enough backlog as it is, and that lets us wait to make sure there aren't any last-minute changes to the syntax. [1] https://github.com/astral-sh/ruff/blob/0bd7a94c2732c232cc1423756e2437d9bce558b1/crates/ty_vendored/ty_extensions/ty_extensions.pyi#L113-L115 https://github.com/astral-sh/ruff/blob/0bd7a94c2732c232cc142... [2] https://github.com/astral-sh/ruff/blob/0bd7a94c2732c232cc1423756e2437d9bce558b1/crates/ty_python_semantic/src/types.rs#L5792 https://github.com/astral-sh/ruff/blob/0bd7a94c2732c232cc142...

maccard 10mo ago

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.

Atomic_Torrfisk 10mo ago

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.

the-wumpus 10mo ago
The existing type checkers are slow. That's their reasoning for creating it. The type checking world in python is now reasonably well specified (and the type checkers are beginning to work more similarly), so I would expect (once ty is out of beta) you could replace your type checker with ty and just see a 20x speedup in CI and much much faster IDE diagnostics. If it was going from 3s -> 1s then you'd probably be right, but on my work codebase pyright (which is the faster one!) takes 15 seconds (ty takes 0.8s) and takes a bit for errors to appear in the IDE. This is now fast enough for us (mypy was taking >30s, which was not fast enough), but if the project grew another order of magnitude (which it might) then it would probably be too slow. It's the same reason ruff is great, linting the codebase is so so fast.

Perepiska 10mo ago

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"

dcreager 10mo ago
There was a hang/performance bug [1, 2] that was reported just after the beta release, which we've since fixed [3]. You might try seeing if we get through your entire project now? (And as an aside, there _is_ a verbose mode: if you add `-vv` you'll get DEBUG-level log messages printing out the name of each file as we start to check it, and you can set TY_MAX_PARALLELISM=1 in your env to make it very clear which file is causing the hang. That's how we debug these kinds of issues when they're reported to us.) [1] https://github.com/astral-sh/ty/issues/1968 https://github.com/astral-sh/ty/issues/1968 [2] https://github.com/astral-sh/ty/issues/1993 https://github.com/astral-sh/ty/issues/1993 [3] https://github.com/astral-sh/ruff/pull/22030 https://github.com/astral-sh/ruff/pull/22030

lucas_membrane 10mo ago

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?