13 ms·

Ty: A fast Python type checker and language server

916 points by arathore 1y ago

pamelafox 1y ago
I am literally checking HackerNews while I wait for mypy to finish running, so I am excited to hear a faster type checker is on the way! Hope the error messages are also helpful.
- dcreager 1y ago
  We're definitely thinking hard about the ergonomics of our error messages! We're drawing inspiration from rustc and miette for the diagnostic model, and are aiming for a quality bar on par with rustc for their content.
tmvphil 1y ago
Just 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.
- mil22 1y ago
  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 https://github.com/microsoft/pyright
  - nine_k 1y ago
    Pyright is good, but it's quite a memory hog. (Yes, I have plenty of RAM on my machine. No, it has other uses during development, too.)
  - bjourne 1y ago
    Pyright is only for type-checking and it lacks many features you'd expected from a modern LSP (I forgot which). Hence, it was forked and someone created basedpyright to fix it: https://github.com/DetachHead/basedpyright https://github.com/DetachHead/basedpyright
    - dathinab 1y ago
      To extend on this: In python it's pretty common to have LSP separate from type checking separate from linting (e.g. ruff+mypy+ide_specific_lsp). Which to be fair sucks (as it limits what the LSP can do, can lead to confusing mismatches in error/no-error and on one recent project I had issues with the default LSP run by vscode starting to fall apart and failing to propose auto imports for some trivial things for part of the project....) But it's the stack where pyright fits in.
      - geekraver 1y ago
        The pylance team has started exploring this, namely whether it makes sense to have an API for type checkers that is not the LSP, as language servers have a somewhat different goal in which type checking/inference is an enabling technology. This could allow multiple different language servers to be built on top of different type checkers (and the type checkers can run out-of-proc, so implementation languages can be different). https://github.com/microsoft/pylance-release/discussions/7180 https://github.com/microsoft/pylance-release/discussions/718...
  - catlover76 1y ago
    [dead]
  - insane_dreamer 1y ago
    in my experience pyright is unable to infer many inherited object types (compared to PyCharm's type inference)
    - lemontheme 1y ago
      PyCharm definitely excels on more ‘dynamic’ code but the number of times I’ve pulled in code written by colleagues using PyCharm only to get a rainbow of type errors from Pyright is too damn high. The PyCharm checker seems to miss really, really obvious things, e.g. allowing a call site to expect a string while the function returns bytes or none. Maybe my colleagues just have it configured wrong but there’s several of them and the config isn’t shared.
  - 0xFF0123 1y ago
    Pyright is incredibly slow in my experience, I've seen it take over a minute on complex codebases
  - mil22 1y ago
    I tested it side-by-side on my ~100Kloc codebase. Ty: 2.5 seconds, 1599 diagnostics, almost all of which are false positives Pyright: 13.6 seconds, 10 errors, all of which are actually real errors There's plenty of potential here, but Ty's type inference is just not as sophisticated as Pyright's at this time. That's not surprising given it hasn't even been released yet. Whether Ty will still perform so much faster once all of Pyright's type inference abilities have been matched or implemented - well, that remains to be seen. Pyright runs on Node, so I would expect it to be a little slower than Ty, but perhaps not by very much, since modern JS engines are already quite fast and perform within a factor of ~2-3x of Rust. That said, I'm rooting for Ty here, since even a 2-3x performance boost would be useful.
    - the_duke 1y ago
      Compilation / type checking depends on a lot of trees of typed data, and operating on those tree nodes. That's something where a statically typed language with custom data structures that allows for optimised representations makes a big difference, and where a lot of the fancy optimisations in v8 don't work so well. There is a reason Typescript moved to a typed language.
      - mil22 1y ago
        Let's hope you're right and that translates to even higher performance for Ty compared to Pyright. There are of course many variables and gotchas with these sorts of things.
  - rtpg 1y ago
    I don't get why so many people go to bat for pyright, my experience with it has been pretty miserable. Open enough instances of it and you're in OOM city. It works, but often gets confused... and of course the absolute audacity of MSFT to say "let's go over to pyright, and by the way we're going to carve up some stuff and put it into pylance instead", meaning that it's totally not within the actual spirit of open source. I would like to just not use it, but the existence of pyright as a _barely_ functional alternative really sucks the air out of other attempts' continued existence. Real "extend/extinguish" behavior from MSFT.
    - lemontheme 1y ago
      If you haven’t checked it out already, basedpyright is pyright with all the arbitrarily carved out functionality put back in – plus some extra features that you may or may not find useful depending on how strict you like your typing. Can’t recommend it enough
      - rtpg 1y ago
        To be honest I can't respect a project that names itself like that. I am a working professional.
    - mil22 1y ago
      I tried all the type checkers available as of ~1 year ago, and Pyright worked the best for me. It's not perfect, but it's better than any of the pure Python checkers. Memory is cheap (unless you're buying it from Apple I guess...). Would I take a faster type checker with better memory footprint? Heck yes, assuming equal or superior functionality.
      - rtpg 1y ago
        Memory ain’t that cheap on laptops in general! The bigger issue is less “pyright” and more “every tool out there being as heavy as pyright” + docker etc… but things are getting better IMO
- js2 1y ago
  I have no doubt that it will be faster than mypy, but: > This project is still in development and is not ready for production use.
- rybosome 1y ago
  > They’ve done it again. Indeed they have. Similar improvement in performance on my side. It is so fast that I thought it must have failed and not actually checked my whole project.
- _carljm 1y ago
  (ty developer here) This is an early preview of a pre-alpha tool, so I would expect a good chunk of those 3500 errors to be wrong at at this point :) Bug reports welcome!
  - joshdavham 1y ago
    Any rough estimates of how much faster you expect ty to be compared to mypy? I'd be super curious to know! I was also one of those people who, when first trying Ruff, assumed that it didn't work the first time I ran it because of how fast it executed!
    - _carljm 1y ago
      We're looking forward to hearing what your experience is! There's a certain amount of roughly-constant overhead (e.g. reading all the files), so generally ty will look relatively faster the larger the project is. For very large projects we've seen up to 50-60x faster or more. We haven't really put a lot of work into targeted optimization yet, so we aim for it to get faster in the future. It will certainly be slower than Ruff, just because multi-file type analysis more complex and less embarrassingly parallel than single-file linting.
Handprint4469 1y ago
If you have uv installed, you can test it without installing by running: uvx ty check
- wdroz 1y ago
  You can also install it "globally" for your user with: uv tool install ty Then you can use it anywhere ty check
  - heavyset_go 1y ago
    Can also do uv tool run ty If your $PATH sucks
- simonw 1y ago
  Here's what I got against one of my larger open source projects: cd /tmp git clone https://github.com/simonw/sqlite-utils cd sqlite-utils uvx ty check Here's the output: https://gist.github.com/simonw/a13e1720b03e23783ae668eca7f6f12a https://gist.github.com/simonw/a13e1720b03e23783ae668eca7f6f... Adding "time uvx ty check" shows it took: uvx ty check 0.18s user 0.07s system 228% cpu 0.109 total
  - diggan 1y ago
    I'm not sure if it's using your environment correctly, or are you expecting ~150 errors? Lots of import errors, and I'm guessing most of the other ones are errors because it couldn't infer what was imported.
  - alexmolas 1y ago
    how does it compare against mypy? is it much faster?
    - IshKebab 1y ago
      How does it compare against Pyright. Pyright is the gold standard of Python type checking currently. Mypy is slower and buggier.
throwaway63467 1y ago
I was wondering when someone would write a type checker in Rust, seemed like an obvious thing to do given how slow mypy is.
- joshdavham 1y ago
  There's Pyrefly if you wanna check it out: https://github.com/facebook/pyrefly https://github.com/facebook/pyrefly
drcongo 1y ago
I've been looking forward to this for what seems like an age.
- codydkdc 1y ago
  how long is an age?
  - tough 1y ago
    a year (probably)?
  - drewcoo 1y ago
    An age is a long amount of time. "An age" is probably an attempted cleaning-up of "a coon's age." https://grammarist.com/usage/coons-age/ https://grammarist.com/usage/coons-age/
  - GuinansEyebrows 1y ago
    in the tolkien legendarium they may be over 3000 years.
  - amelius 1y ago
    We're living in the information age. Not sure when or what the next age will be, but you get the idea.
    - arijun 1y ago
      Pretty sure we’ve already made it to the disinformation age.
  - deleted 1y ago
    [deleted]
nickagliano 1y ago
Interesting 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.
- tasn 1y ago
  Astral announced it last year I think, so it's been a long time coming.
- emptysea 1y ago
  Also interesting, pyrefly uses Ruff’s parser! https://github.com/facebook/pyrefly/blob/a8626110da034f8e513f0a6d22f3126cdd11f0dd/pyrefly/Cargo.toml#L52 https://github.com/facebook/pyrefly/blob/a8626110da034f8e513...
- ipsum2 1y ago
  Pyrefly is a rewrite of Pyre, a Python typechecker which has been around for 4-5 years. Pyre is the strictest type checker I've used, compared to mypy, but its kind of a pain to set up.
- masklinn 1y ago
  > Interesting to see astral come out with this right around facebook’s release Astral announced they were building a typechecker back in January: https://x.com/charliermarsh/status/1884651482009477368 https://x.com/charliermarsh/status/1884651482009477368
- zem 1y ago
  language tooling is a sweet spot for rust, for sure.
- akdor1154 1y ago
  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.)
kodablah 1y ago
Fingers crossed this is/becomes extensible. Pyright and MyPy both suffer from lack of extensibility IMO (Pyright doesn't consider the use case and MyPy plugins come across as an afterthought with limited capabilities). There are many things that can be built on the back of type-checked AST.
- andenacitelli 1y ago
  I’ve had this same thought. Ruff doesn’t support extensions / custom lint rules that I’m aware of, so maybe don’t get your hopes up.
  - the_mitsuhiko 1y ago
    Not supporting plugins for a type checker to me is a plus. It’s quite frustrating that some Python projects only typecheck if you have plugins. That is a major source of frustration.
    - Redoubts 1y ago
      I mean that kind of code exists; things like attrs are too magical otherwise
    - zem 1y ago
      python packages that do a lot of metaprot can only be properly type checked if you replicate that metaprogramming at the type level. e.g. if dataclasses were not part of the standard library they would need a plug-in to be handled correctly.
- notatallshaw 1y ago
  Charlie already said in a podcast (https://www.youtube.com/watch?v=XVwpL_cAvrw https://www.youtube.com/watch?v=XVwpL_cAvrw) that they are not looking to make it extensible. That it's considered a feature that type checking works interchangeably across tools and projects. Ruff's linting and formatting is more likely to get plugin/extension support at some point in the future.
aleksanb 1y ago
The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. The reason we're stuck on mypy at work is because it's the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods. I wish more python tooling took the TS approach of "what's in the wild IS the language", as opposed to a "we only typecheck the constructs we think you SHOULD be using".
- mjr00 1y ago
  > The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. Or in this case, writing it in Rust... mypy is written in Python. People have forgotten that Python is really, really slow for CPU-intensive operations. Python's performance may not matter when you're writing web service code and the bottlenecks are database I/O and network calls, but for a tool that's loading up files, parsing into an AST, etc, it's no surprise that Rust/C/even Go would be an order of magnitude or two faster than Python. uv and ruff have been fantastic for me. ty is definitely not production ready (I see several bizarre issues on a test codebase, such as claiming `datetime.UTC` doesn't exist) but I trust that Astral will match the "crazy reality" of real Python (which I agree, is very crazy).
  - _carljm 1y ago
    (ty developer here) Currently we default to our oldest supported Python version, in which `datetime.UTC` really doesn't exist! Use `--python-version 3.12` on the CLI, or add a `ty.toml` with e.g. ``` [environment] python-version = "3.12" ``` And we'll find `datetime.UTC`. We've discussed that this is probably the wrong default, and plan to change it.
    - mjr00 1y ago
      aha makes sense! Yeah it'd be nice if you could divine the intended python version from the uv configuration/`.python-version`. Thanks for all your hard work, looking forward to the full release!
    - 1y ago
krupan 1y ago
Have these guys figured out how to make money yet?
- dcreager 1y ago
  We're going to set up a lemonade stand in the main hall at PyCon next week
  - digdugdirk 1y ago
    Fingers crossed this isn't a joke.
    - dcreager 1y ago
      Well, it is a joke...but that said, we're hosting a happy hour which is kinda similar! https://partiful.com/e/Dcrv6XA8PjWTK5Zhw8yr https://partiful.com/e/Dcrv6XA8PjWTK5Zhw8yr
      - bb88 1y ago
        I'm looking forward to talking with you guys.
      - ensignavenger 1y ago
        But are you going to actually make money from it? I am quite leery of companies releasing awesome open source code, growing and taking on massive financing (based largely on that growth, which they achieved because of being open source) then after becoming entrenched in the market, bitching and whining about not "capturing enough value" from their open source code. (And often, switching to an non open source license, while simultaneously declaring their love for open source!) Now, I know you folks haven't ever done that, but it is such a pattern lately that I almost expect it from any for profit company whose primary product is open source. I don't want to judge you based on the actions of others... but the pattern is so well established now that I have to exercise caution. Now, in the end, I simply switch to whatever open source fork or alternative crops up (or already exists). But it makes it hard for me to go "Hey everyone, you should be using Astral's X because they are awesome and X is awesome and X is open source. And do 'y'[code contributions, financial sponsorship, buy support from them- whatever it might be] to make sure to support Astral and their development of the open source X code!" ... because I am anticipating the rug pull, taking the trademark and brand down the tube with it. Yet, I really, really, really want to support you folks. I want to tell everyone about your great products. I want to encourage them to use your product and to support you financially.
zanie 1y ago
: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. Stay tuned for more for news in the near future! (... I work at Astral)
- theLiminator 1y ago
  Curious if this means it'll be released as a separate binary than ruff? I personally feel like having it within ruff is much nicer for ensuring that we have a consistent set of dependencies that play nicely with each other. Though I guess because a type checker doesn't mutate the files maybe that's not a real concern (vs formatting/linting with --fix).
  - zanie 1y ago
    It'll be separate (at least to start) — we want to be able to iterate on it rapidly. Long-term, a consistent toolchain is definitely important and something we're thinking about.
  - skwashd 1y ago
    +1 for (eventually) baking it ty into ruff. In my mind static type checking is a form of linting. For years I pushed black for formatting code. Once formatting was baked into ruff I ditched black. Having fewer dependencies to track and update simplifies my life and shortens my dependabot queue.
- 12_throw_away 1y ago
  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.)
simlevesque 1y ago
I installed it in VSCode and removed Mypy, I haven't looked back: https://marketplace.visualstudio.com/items/?itemName=astral-sh.ty https://marketplace.visualstudio.com/items/?itemName=astral-...
tayo42 1y ago
Curious why so many people want to implement type checkers for python? What problems are being solved that aren't covered already?
- simonw 1y ago
  Speed.
  - alexwaygood 1y ago
    That's a big part of it, but there are also several areas where we're trying to innovate on functionality as well as speed. I'd personally be pretty disappointed if the only thing we had to offer at the end of all this was a type checker where the only value add was speed. We've also got first-class support for intersection types, and quite a different model to other type checkers regarding when and whether redefinitions are allowed, for example. We believe there are significant areas where typing can be made more usable and easily adoptable than it is today.
- mvieira38 1y ago
  The ones that are around are slow, and working with untyped Python is a pain in large codebases
- dathinab 1y ago
  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)).
f311a 1y ago
Does it support go to definition and other lsp features?
- dcreager 1y ago
  We do plan to provide an LSP server and VS Code plugin, which will support GTD etc. Though as several others have pointed out (e.g. https://news.ycombinator.com/item?id=43919354 https://news.ycombinator.com/item?id=43919354), it's still very early days for ty, so we don't have concrete release announcements for that yet.
  - darkteflon 1y ago
    The VS Code extension is linked in one of the above comments. Accepting that it’s early days and all, but … if someone _really_ hated Pylance, could they replace it with ty for hobby projects and get most of the same headline functionality? Thanks for all your great work! Love ruff, rye/uv.
    - _carljm 1y ago
      Not the same headline functionality yet, no. At the moment all we support is diagnostics (some of which may be wrong) and go-to-type-definition. More will come.
      - darkteflon 1y ago
        Thanks for the indulgence. My question was unreasonable, upon reflection, in light of the other information you’ve already provided in the thread.
    - Hasnep 1y ago
      Depending on the reason you hate Pylance, you could try basedpyright instead https://docs.basedpyright.com/v1.18.4/installation/ides/ https://docs.basedpyright.com/v1.18.4/installation/ides/
cristea 1y ago
Will it support Django stubs? Only blocker for my company to switch
joejoo 1y ago
Astral killing it with the Python tooling.
rexledesma 1y ago
Very excited to have a new fully featured Python language server working in both vscode and vscode forks (e.g. Windsurf, Cursor). Pylance is borked on these forked distributions, so having a new solid alternative here that doesn't involve adopting yet another forked Pyright implementation (BasedPyright, Cursor Pyright, Windsurf Pyright, ...) sounds great to me.
- maxloh 1y ago
  You should try basedpyright: https://docs.basedpyright.com/latest/ https://docs.basedpyright.com/latest/ > basedpyright re-implements many features exclusive to pylance - microsoft's closed-source extension that can't be used outside of vscode.
  - rexledesma 1y ago
    I mentioned it in my initial comment. Ideally, I would like to use the same type checker/LSP for a language everywhere (any of my local editors, CI/CD). This is especially important when working in a team setting. It doesn't feel great to use a forked type checker/LSP that's not enforced in your org's CI/CD. And it also doesn't feel great to force the forked type checker onto the entire organization when only a subset of folks may be using a forked vscode editor.
ngoldbaum 1y ago
I gave away the “ty” project name on pypi to Astral a week or so ago. I wanted to use it for a joke a few years ago but this is a much better use for a two letter project name. They agreed to make a donation to the PSF to demonstrate their gratefulness.
- Celeo 1y ago
  I love this outcome; kudos to you and Astral both!
- swyx 1y ago
  thanks for not charging obnoxious amounts for package names!
- smitty1e 1y ago
  ty--thank you
- deleted 1y ago
  [deleted]
- _carljm 1y ago
  Yes, thank you for your graciousness and generosity, very much appreciated.
- rrszynka 1y ago
  nice! what was the planned joke?
  - ngoldbaum 1y ago
    Either something about beanie babies or something riffing on "thank you". Couldn't ever make up my mind then basically forgot about it.
urbandw311er 1y ago
It’s like when we hit a new month the quota of “talk about Rust” credits is renewed.
- andenacitelli 1y ago
  Say what you want, Astral ships impressively fast and their stuff works well. Python has been looking for better tooling for a long time.
- rc00 1y ago
  The timing of the recent batch of propaganda makes it hard to believe it's not coordinated. I wouldn't suggest paid actors but maybe just an attempt to counter some fairly visible and negative recent takes. The amount of "I love Rust but" comments make it hard to take the commentary seriously too.
  - Philpax 1y ago
    Is it really that hard to believe that people like the language and the problems it solves for them?
    - urbandw311er 1y ago
      I think what stands out (and becomes quite tedious) is that most posts on HN don’t tend to include the language choice in the headline. So a typical HN post might be “A new widget that saves times rendering Python code”. Whereas we get this constant barrage of “A new widget that saves times rendering Python code in Rust” with Rust appended to it.
      - urbandw311er 1y ago
        PS: just to explain, the original post title was like this but it has now been modified to remove Rust.
joshdavham 1y ago
Any plans to create an official ty github action? I've been loving the ruff github action.
sestep 1y ago
Is this the same thing as Red Knot?
- _carljm 1y ago
  Yes, red knot was the internal development code name; ty is the actual name.
robertwt7 1y ago
This will be similar to Typescript I assume? If so I can’t wait to use it!! I cant count how many times I’ve searched for “TS like in Python” since I’ve started working on Python codebase. TS is so awesome that I use it 100% on new projects. Ruff is also very good, but with this, large code base Python will be a breeze to work with
- IshKebab 1y ago
  You can already use static type annotations in Python and check them with Pyright. This will just make it faster. Also currently the Python IDE support (autocompletion, refactoring, etc.) in VSCode is provided by Pylance which is closed source, so this would provide an open source alternative to that.
briandw 1y ago
Looks good but it has the same issues that i have with mypy. Packages that don't include the type hints blow-up my process. In mypy i've come to terms with strategically ignoring packages or finding a package of type hints. Mypy is runs cleanly on my project but I get >800 errors with TY, mostly things like: lint:unresolved-import: Cannot resolve imported module `pydantic` --> vartia/usr_id.py:4:6 | 2 | from typing import Optional, Any 3 | from enum import Enum 4 | from pydantic import BaseModel, ConfigDict looking forward to the release version.
- _carljm 1y ago
  The current version can handle importing pydantic without error just fine, but it probably can't find your virtualenv, so it doesn't know what third-party dependencies you have installed. Ty will discover your venv if it is in `.venv` in the project directory; otherwise you can help it out with the `--python` CLI flag.
  - alexwaygood 1y ago
    We'll also discover your venv if you: - Activate it manually (`source .venv/bin/activate`, etc.) - Set the `VIRTUAL_ENV` environment variable - Or use a command such as `uv run` or the equivalent from pdm/poetry/hatch to run ty (these project managers usually implicitly set the `VIRTUAL_ENV` variable to point to the project's virtual environment before executing any commands)
pizza 1y ago
Probably not a top priority but it would be really really cool if this thing had solid t-string support from the jump, to the extent that it’s feasible without actually executing code
rowanG077 1y ago
Recently I started a python project and I wanted to do it the "proper" way. mypy + pylint. But even on this small 15-20kloc program these tools are way to slow to do anything in realtime. It takes double digit seconds to have feedback. Way to long for an LSP. I'm honestly appalled the state of affairs is this bad. What the hell do people do with moderately or even large sized code bases?
- mil22 1y ago
  Pyright + Pylance + Ruff has been rock solid for me on my 100Kloc codebase for more than a year now. I use the VS Code extensions, and Pyright and Ruff are integrated into my pre-commit.
- catlover76 1y ago
  [dead]
- Hasnep 1y ago
  They probably use (based)pyright which is much faster than mypy and ruff which is much much much faster than pylint.
Affric 1y ago
See the thing about astral is that they get why Python has been successful in the first place: When it was released it might have been one of the easiest to use languages. The focus on tooling and making the tooling fast has been sharp. Seeing people recommend using non-astral tooling seems nuts at this point.
blibble 1y ago
prior to astral appearing, python's tooling has been beyond terrible, compared to say, Java's astral have now replaced the awful pip with the fantastic uv various awful linters with with the fantastic ruff and now hopefully replacing the terrible type checkers (e.g. mypy) with a good one! I hope they have the pypi backend on their list too, my kingdom for Maven Central in python!
- danlamanna 1y ago
  > I hope they have the pypi backend on their list too IIRC they have floated the idea of private registries as a commercial offering in the past.
- kokada 1y ago
  > prior to astral appearing, python's tooling has been beyond terrible, compared to say, Java's I would concur with you if you said Go, Rust, Ruby, or even heck, PHP, but Java is probably the only language that I know that is in a situation even as bad as Python or even worse (at least for me definitely worse, because at least I understand Python tooling enough even when using it only for hobby projects, while I still don't understand Java tooling enough even after working professionally with JVM languages for 7+ years). Java is the only language that I know except Python that has multiple project/package managers (Maven, Gradle, probably even more). It also has no concept of lock files in at least Maven/Gradle, and while resolution dependency in Maven/Gradle is supposed to be deterministic, from my experience it is anything but: just a few weeks ago we had a deployment that failed but worked locally/CI because of dependency resolution somehow pulled different versions of the same library. Fighting dependency hell because different dependencies pull different version constraints is a pain (all Java/JVM projects that I ever worked had some manually pinned dependencies to either fix security issues or to fix broken dependency resolution), and don't even get me in the concept of Uber JARs (that we had to use in previous job because it was the only way to ensure that the dependency tree would be solved correctly; yes maybe it was by incompetence of the team that maintained our shared libraries, but the fact that we even got at that situation is unacceptable). Oh, and also Gradle is "so fun": it is a DSL that has zero discovery (I had IntelliJ IDEA Ultimate and I could still not get it to auto-complete 60% of the time), so I would just blindly try to discover what where the inputs of the functions. The documentation didn't help because the DSL was so dynamic and every project would use it slightly different, so it was really difficult to discover a way to make it work for that specific project (the examples that I would find would be enough different from my current project that 90% of time it wouldn't work without changing something). Python at least has `pyproject.toml` nowadays, and the documentation from PyPA is good enough that you can understand what you want to do after reading it for 10 minutes.
canterburry 1y ago
How about we just stop creating non type safe languages. Would save everyone so much hassle. [bring on the downvotes]
- codr7 1y ago
  You're begging for it. Not every situation calls for type safe languages, you're projecting a preference.
- Hasnep 1y ago
  It's a bit late now that python has existed for a couple of decades
  - canterburry 1y ago
    How about put it on the roadmap for v4?
ljouhet 1y ago
uv 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 ...`
- pt_PT_guy 1y ago
  don't forget ruff checker and formatter
tiltowait 1y ago
I've been looking forward to this since the original announcement (and before, really). On the modest codebase I tried it on (14k LOC across 126 files), it runs in 149ms compared to 1.66s in pyright (both run via uvx <tool>). I couldn't get it to play nicely with a poetry project, but it works fine (obviously) in a uv project. Definitely some false-positives, as expected. Interestingly, it seems to hate the `dict()` initializer (e.g. `dict(foo="bar")`).
- SOLAR_FIELDS 1y ago
  Only one order of magnitude? I thought it would be 2. Isn’t ruff 400x faster than the fastest Python alternative?
  - Philpax 1y ago
    A type checker is much more algorithmically bound / difficult to parallelise, but I'm sure there are still wins to be had in the future.
cyounkins 1y ago
How does Astral plan on making money?
- preciousoo 1y ago
  CI/CD products most likely, or something more futuristic in that line
  - nindalf 1y ago
    CI/CD, private repositories, providing hosting. These are the options used by similar companies. But I like that they’re focussing on creating something useful before chasing revenue. Once they’ve got a single tool that provides a consistent dev experience for Python developers and it’s widely adopted they should be able to pursue monetisation easily.
    - anentropic 1y ago
      "Step 3: profit!"
    - Philpax 1y ago
      I think that's a bit optimistic; that's the path every VC-funded tooling company tries to take, and it often doesn't end well; restrictive licenses, hostile forks, early deaths, etc. You need to have some kind of plan ahead of time.
ivanbelenky 1y ago
holy shit this is happening
selfselfgo 1y ago
[dead]
deleted 1y ago
[deleted]
Sarios 1y ago
Perhaps a silly question. Will ty be usable for getting semantical completions / suggestions. Similar to using pyright to get completions based on what's being written.
- dcreager 1y ago
  We are planning on shipping an LSP front end, and the goal is for that to include code completions. Though to set expectations, they will probably not be that sophisticated on day one. There's a lot of interesting work that we could do here, but it will take time!
  - Sarios 1y ago
    You guys take your time and enjoy yourselves :). You have a proven record of making good tools, so if this part takes a while, let it take a while.
no_time 1y ago
Awesome work. What is the business model for these astral tools? It’s a bit of a “waiting for the other shoe to drop” feeling after seeing the VC backing on the company page.
- lemontheme 1y ago
  From what I’ve gathered (because I had similar concerns), the code is properly open source. In the very worst case, should there ever come a rug pull, it can be forked.
  - dcreager 1y ago
    The code is definitely open source from a licensing perspective, but we are also trying to ensure that a healthy community forms around our tools as well. We've been developing ty in the open for the last year or so, and it already includes significant work from external contributors. This is definitely not a project where only Astral-paid engineers can contribute.
    - Tryk 1y ago
      That's cool. So can you elaborate on how your long-term profitability is projected? Of course there would not be too much point in contributing to a project that gets aggressively monetized in the near future.
The-Ludwig 1y ago
If this will be only 50% as awesome as ruff or uv, it will be a future must-have for me.
hamandcheese 1y ago
Not the most fun question, but as I see Astral taking over the python ecosystem, I can't help but wonder: how do y'all plan to make money? It seems like you've taken VC funding, so monetization is inevitable.
- renmillar 1y ago
  Yes, are they going for enterprise licensing or something similar to JetBrains' approach?
- zanie 1y ago
  The plan remains the same as when the company was announced (https://astral.sh/blog/announcing-astral-the-company-behind-ruff#whats-next https://astral.sh/blog/announcing-astral-the-company-behind-...) — paid services that build on and integrate with the free tooling.
TeeMassive 1y ago
Glad to see that we have the type-checking equivalent of Ruff!
dhruv3006 1y ago
Great job!

916 points by arathore 1y ago

I am literally checking HackerNews while I wait for mypy to finish running, so I am excited to hear a faster type checker is on the way! Hope the error messages are also helpful.

dcreager 1y ago
We're definitely thinking hard about the ergonomics of our error messages! We're drawing inspiration from rustc and miette for the diagnostic model, and are aiming for a quality bar on par with rustc for their content.

tmvphil 1y ago

Just 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.

mil22 1y ago
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 https://github.com/microsoft/pyright
- nine_k 1y ago
  Pyright is good, but it's quite a memory hog. (Yes, I have plenty of RAM on my machine. No, it has other uses during development, too.)
- bjourne 1y ago
  Pyright is only for type-checking and it lacks many features you'd expected from a modern LSP (I forgot which). Hence, it was forked and someone created basedpyright to fix it: https://github.com/DetachHead/basedpyright https://github.com/DetachHead/basedpyright
  - dathinab 1y ago
    To extend on this: In python it's pretty common to have LSP separate from type checking separate from linting (e.g. ruff+mypy+ide_specific_lsp). Which to be fair sucks (as it limits what the LSP can do, can lead to confusing mismatches in error/no-error and on one recent project I had issues with the default LSP run by vscode starting to fall apart and failing to propose auto imports for some trivial things for part of the project....) But it's the stack where pyright fits in.
    - geekraver 1y ago
      The pylance team has started exploring this, namely whether it makes sense to have an API for type checkers that is not the LSP, as language servers have a somewhat different goal in which type checking/inference is an enabling technology. This could allow multiple different language servers to be built on top of different type checkers (and the type checkers can run out-of-proc, so implementation languages can be different). https://github.com/microsoft/pylance-release/discussions/7180 https://github.com/microsoft/pylance-release/discussions/718...
- catlover76 1y ago
  [dead]
- insane_dreamer 1y ago
  in my experience pyright is unable to infer many inherited object types (compared to PyCharm's type inference)
  - lemontheme 1y ago
    PyCharm definitely excels on more ‘dynamic’ code but the number of times I’ve pulled in code written by colleagues using PyCharm only to get a rainbow of type errors from Pyright is too damn high. The PyCharm checker seems to miss really, really obvious things, e.g. allowing a call site to expect a string while the function returns bytes or none. Maybe my colleagues just have it configured wrong but there’s several of them and the config isn’t shared.
- 0xFF0123 1y ago
  Pyright is incredibly slow in my experience, I've seen it take over a minute on complex codebases
- mil22 1y ago
  I tested it side-by-side on my ~100Kloc codebase. Ty: 2.5 seconds, 1599 diagnostics, almost all of which are false positives Pyright: 13.6 seconds, 10 errors, all of which are actually real errors There's plenty of potential here, but Ty's type inference is just not as sophisticated as Pyright's at this time. That's not surprising given it hasn't even been released yet. Whether Ty will still perform so much faster once all of Pyright's type inference abilities have been matched or implemented - well, that remains to be seen. Pyright runs on Node, so I would expect it to be a little slower than Ty, but perhaps not by very much, since modern JS engines are already quite fast and perform within a factor of ~2-3x of Rust. That said, I'm rooting for Ty here, since even a 2-3x performance boost would be useful.
  - the_duke 1y ago
    Compilation / type checking depends on a lot of trees of typed data, and operating on those tree nodes. That's something where a statically typed language with custom data structures that allows for optimised representations makes a big difference, and where a lot of the fancy optimisations in v8 don't work so well. There is a reason Typescript moved to a typed language.
    - mil22 1y ago
      Let's hope you're right and that translates to even higher performance for Ty compared to Pyright. There are of course many variables and gotchas with these sorts of things.
- rtpg 1y ago
  I don't get why so many people go to bat for pyright, my experience with it has been pretty miserable. Open enough instances of it and you're in OOM city. It works, but often gets confused... and of course the absolute audacity of MSFT to say "let's go over to pyright, and by the way we're going to carve up some stuff and put it into pylance instead", meaning that it's totally not within the actual spirit of open source. I would like to just not use it, but the existence of pyright as a _barely_ functional alternative really sucks the air out of other attempts' continued existence. Real "extend/extinguish" behavior from MSFT.
  - lemontheme 1y ago
    If you haven’t checked it out already, basedpyright is pyright with all the arbitrarily carved out functionality put back in – plus some extra features that you may or may not find useful depending on how strict you like your typing. Can’t recommend it enough
    - rtpg 1y ago
      To be honest I can't respect a project that names itself like that. I am a working professional.
  - mil22 1y ago
    I tried all the type checkers available as of ~1 year ago, and Pyright worked the best for me. It's not perfect, but it's better than any of the pure Python checkers. Memory is cheap (unless you're buying it from Apple I guess...). Would I take a faster type checker with better memory footprint? Heck yes, assuming equal or superior functionality.
    - rtpg 1y ago
      Memory ain’t that cheap on laptops in general! The bigger issue is less “pyright” and more “every tool out there being as heavy as pyright” + docker etc… but things are getting better IMO
js2 1y ago
I have no doubt that it will be faster than mypy, but: > This project is still in development and is not ready for production use.
rybosome 1y ago
> They’ve done it again. Indeed they have. Similar improvement in performance on my side. It is so fast that I thought it must have failed and not actually checked my whole project.
_carljm 1y ago
(ty developer here) This is an early preview of a pre-alpha tool, so I would expect a good chunk of those 3500 errors to be wrong at at this point :) Bug reports welcome!
- joshdavham 1y ago
  Any rough estimates of how much faster you expect ty to be compared to mypy? I'd be super curious to know! I was also one of those people who, when first trying Ruff, assumed that it didn't work the first time I ran it because of how fast it executed!
  - _carljm 1y ago
    We're looking forward to hearing what your experience is! There's a certain amount of roughly-constant overhead (e.g. reading all the files), so generally ty will look relatively faster the larger the project is. For very large projects we've seen up to 50-60x faster or more. We haven't really put a lot of work into targeted optimization yet, so we aim for it to get faster in the future. It will certainly be slower than Ruff, just because multi-file type analysis more complex and less embarrassingly parallel than single-file linting.

Handprint4469 1y ago

If you have uv installed, you can test it without installing by running: uvx ty check

wdroz 1y ago
You can also install it "globally" for your user with: uv tool install ty Then you can use it anywhere ty check
- heavyset_go 1y ago
  Can also do uv tool run ty If your $PATH sucks
simonw 1y ago
Here's what I got against one of my larger open source projects: cd /tmp git clone https://github.com/simonw/sqlite-utils cd sqlite-utils uvx ty check Here's the output: https://gist.github.com/simonw/a13e1720b03e23783ae668eca7f6f12a https://gist.github.com/simonw/a13e1720b03e23783ae668eca7f6f... Adding "time uvx ty check" shows it took: uvx ty check 0.18s user 0.07s system 228% cpu 0.109 total
- diggan 1y ago
  I'm not sure if it's using your environment correctly, or are you expecting ~150 errors? Lots of import errors, and I'm guessing most of the other ones are errors because it couldn't infer what was imported.
- alexmolas 1y ago
  how does it compare against mypy? is it much faster?
  - IshKebab 1y ago
    How does it compare against Pyright. Pyright is the gold standard of Python type checking currently. Mypy is slower and buggier.

throwaway63467 1y ago

I was wondering when someone would write a type checker in Rust, seemed like an obvious thing to do given how slow mypy is.

joshdavham 1y ago
There's Pyrefly if you wanna check it out: https://github.com/facebook/pyrefly https://github.com/facebook/pyrefly

drcongo 1y ago

I've been looking forward to this for what seems like an age.

codydkdc 1y ago
how long is an age?
- tough 1y ago
  a year (probably)?
- drewcoo 1y ago
  An age is a long amount of time. "An age" is probably an attempted cleaning-up of "a coon's age." https://grammarist.com/usage/coons-age/ https://grammarist.com/usage/coons-age/
- GuinansEyebrows 1y ago
  in the tolkien legendarium they may be over 3000 years.
- amelius 1y ago
  We're living in the information age. Not sure when or what the next age will be, but you get the idea.
  - arijun 1y ago
    Pretty sure we’ve already made it to the disinformation age.
- deleted 1y ago
  [deleted]

nickagliano 1y ago

Interesting 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.

tasn 1y ago
Astral announced it last year I think, so it's been a long time coming.
emptysea 1y ago
Also interesting, pyrefly uses Ruff’s parser! https://github.com/facebook/pyrefly/blob/a8626110da034f8e513f0a6d22f3126cdd11f0dd/pyrefly/Cargo.toml#L52 https://github.com/facebook/pyrefly/blob/a8626110da034f8e513...
ipsum2 1y ago
Pyrefly is a rewrite of Pyre, a Python typechecker which has been around for 4-5 years. Pyre is the strictest type checker I've used, compared to mypy, but its kind of a pain to set up.
masklinn 1y ago
> Interesting to see astral come out with this right around facebook’s release Astral announced they were building a typechecker back in January: https://x.com/charliermarsh/status/1884651482009477368 https://x.com/charliermarsh/status/1884651482009477368
zem 1y ago
language tooling is a sweet spot for rust, for sure.
akdor1154 1y ago
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.)

kodablah 1y ago

Fingers crossed this is/becomes extensible. Pyright and MyPy both suffer from lack of extensibility IMO (Pyright doesn't consider the use case and MyPy plugins come across as an afterthought with limited capabilities). There are many things that can be built on the back of type-checked AST.

andenacitelli 1y ago
I’ve had this same thought. Ruff doesn’t support extensions / custom lint rules that I’m aware of, so maybe don’t get your hopes up.
- the_mitsuhiko 1y ago
  Not supporting plugins for a type checker to me is a plus. It’s quite frustrating that some Python projects only typecheck if you have plugins. That is a major source of frustration.
  - Redoubts 1y ago
    I mean that kind of code exists; things like attrs are too magical otherwise
  - zem 1y ago
    python packages that do a lot of metaprot can only be properly type checked if you replicate that metaprogramming at the type level. e.g. if dataclasses were not part of the standard library they would need a plug-in to be handled correctly.
notatallshaw 1y ago
Charlie already said in a podcast (https://www.youtube.com/watch?v=XVwpL_cAvrw https://www.youtube.com/watch?v=XVwpL_cAvrw) that they are not looking to make it extensible. That it's considered a feature that type checking works interchangeably across tools and projects. Ruff's linting and formatting is more likely to get plugin/extension support at some point in the future.

aleksanb 1y ago

The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. The reason we're stuck on mypy at work is because it's the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods. I wish more python tooling took the TS approach of "what's in the wild IS the language", as opposed to a "we only typecheck the constructs we think you SHOULD be using".

mjr00 1y ago
> The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. Or in this case, writing it in Rust... mypy is written in Python. People have forgotten that Python is really, really slow for CPU-intensive operations. Python's performance may not matter when you're writing web service code and the bottlenecks are database I/O and network calls, but for a tool that's loading up files, parsing into an AST, etc, it's no surprise that Rust/C/even Go would be an order of magnitude or two faster than Python. uv and ruff have been fantastic for me. ty is definitely not production ready (I see several bizarre issues on a test codebase, such as claiming `datetime.UTC` doesn't exist) but I trust that Astral will match the "crazy reality" of real Python (which I agree, is very crazy).
- _carljm 1y ago
  (ty developer here) Currently we default to our oldest supported Python version, in which `datetime.UTC` really doesn't exist! Use `--python-version 3.12` on the CLI, or add a `ty.toml` with e.g. ``` [environment] python-version = "3.12" ``` And we'll find `datetime.UTC`. We've discussed that this is probably the wrong default, and plan to change it.
  - mjr00 1y ago
    aha makes sense! Yeah it'd be nice if you could divine the intended python version from the uv configuration/`.python-version`. Thanks for all your hard work, looking forward to the full release!
  - 1y ago

krupan 1y ago

Have these guys figured out how to make money yet?

dcreager 1y ago
We're going to set up a lemonade stand in the main hall at PyCon next week
- digdugdirk 1y ago
  Fingers crossed this isn't a joke.
  - dcreager 1y ago
    Well, it is a joke...but that said, we're hosting a happy hour which is kinda similar! https://partiful.com/e/Dcrv6XA8PjWTK5Zhw8yr https://partiful.com/e/Dcrv6XA8PjWTK5Zhw8yr
    - bb88 1y ago
      I'm looking forward to talking with you guys.
    - ensignavenger 1y ago
      But are you going to actually make money from it? I am quite leery of companies releasing awesome open source code, growing and taking on massive financing (based largely on that growth, which they achieved because of being open source) then after becoming entrenched in the market, bitching and whining about not "capturing enough value" from their open source code. (And often, switching to an non open source license, while simultaneously declaring their love for open source!) Now, I know you folks haven't ever done that, but it is such a pattern lately that I almost expect it from any for profit company whose primary product is open source. I don't want to judge you based on the actions of others... but the pattern is so well established now that I have to exercise caution. Now, in the end, I simply switch to whatever open source fork or alternative crops up (or already exists). But it makes it hard for me to go "Hey everyone, you should be using Astral's X because they are awesome and X is awesome and X is open source. And do 'y'[code contributions, financial sponsorship, buy support from them- whatever it might be] to make sure to support Astral and their development of the open source X code!" ... because I am anticipating the rug pull, taking the trademark and brand down the tube with it. Yet, I really, really, really want to support you folks. I want to tell everyone about your great products. I want to encourage them to use your product and to support you financially.

zanie 1y ago

: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. Stay tuned for more for news in the near future! (... I work at Astral)

theLiminator 1y ago
Curious if this means it'll be released as a separate binary than ruff? I personally feel like having it within ruff is much nicer for ensuring that we have a consistent set of dependencies that play nicely with each other. Though I guess because a type checker doesn't mutate the files maybe that's not a real concern (vs formatting/linting with --fix).
- zanie 1y ago
  It'll be separate (at least to start) — we want to be able to iterate on it rapidly. Long-term, a consistent toolchain is definitely important and something we're thinking about.
- skwashd 1y ago
  +1 for (eventually) baking it ty into ruff. In my mind static type checking is a form of linting. For years I pushed black for formatting code. Once formatting was baked into ruff I ditched black. Having fewer dependencies to track and update simplifies my life and shortens my dependabot queue.
12_throw_away 1y ago
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.)

simlevesque 1y ago

I installed it in VSCode and removed Mypy, I haven't looked back: https://marketplace.visualstudio.com/items/?itemName=astral-sh.ty https://marketplace.visualstudio.com/items/?itemName=astral-...

tayo42 1y ago

Curious why so many people want to implement type checkers for python? What problems are being solved that aren't covered already?

simonw 1y ago
Speed.
- alexwaygood 1y ago
  That's a big part of it, but there are also several areas where we're trying to innovate on functionality as well as speed. I'd personally be pretty disappointed if the only thing we had to offer at the end of all this was a type checker where the only value add was speed. We've also got first-class support for intersection types, and quite a different model to other type checkers regarding when and whether redefinitions are allowed, for example. We believe there are significant areas where typing can be made more usable and easily adoptable than it is today.
mvieira38 1y ago
The ones that are around are slow, and working with untyped Python is a pain in large codebases
dathinab 1y ago
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)).

f311a 1y ago

Does it support go to definition and other lsp features?

dcreager 1y ago
We do plan to provide an LSP server and VS Code plugin, which will support GTD etc. Though as several others have pointed out (e.g. https://news.ycombinator.com/item?id=43919354 https://news.ycombinator.com/item?id=43919354), it's still very early days for ty, so we don't have concrete release announcements for that yet.
- darkteflon 1y ago
  The VS Code extension is linked in one of the above comments. Accepting that it’s early days and all, but … if someone _really_ hated Pylance, could they replace it with ty for hobby projects and get most of the same headline functionality? Thanks for all your great work! Love ruff, rye/uv.
  - _carljm 1y ago
    Not the same headline functionality yet, no. At the moment all we support is diagnostics (some of which may be wrong) and go-to-type-definition. More will come.
    - darkteflon 1y ago
      Thanks for the indulgence. My question was unreasonable, upon reflection, in light of the other information you’ve already provided in the thread.
  - Hasnep 1y ago
    Depending on the reason you hate Pylance, you could try basedpyright instead https://docs.basedpyright.com/v1.18.4/installation/ides/ https://docs.basedpyright.com/v1.18.4/installation/ides/

cristea 1y ago

Will it support Django stubs? Only blocker for my company to switch

joejoo 1y ago

Astral killing it with the Python tooling.

rexledesma 1y ago

Very excited to have a new fully featured Python language server working in both vscode and vscode forks (e.g. Windsurf, Cursor). Pylance is borked on these forked distributions, so having a new solid alternative here that doesn't involve adopting yet another forked Pyright implementation (BasedPyright, Cursor Pyright, Windsurf Pyright, ...) sounds great to me.

maxloh 1y ago
You should try basedpyright: https://docs.basedpyright.com/latest/ https://docs.basedpyright.com/latest/ > basedpyright re-implements many features exclusive to pylance - microsoft's closed-source extension that can't be used outside of vscode.
- rexledesma 1y ago
  I mentioned it in my initial comment. Ideally, I would like to use the same type checker/LSP for a language everywhere (any of my local editors, CI/CD). This is especially important when working in a team setting. It doesn't feel great to use a forked type checker/LSP that's not enforced in your org's CI/CD. And it also doesn't feel great to force the forked type checker onto the entire organization when only a subset of folks may be using a forked vscode editor.

ngoldbaum 1y ago

I gave away the “ty” project name on pypi to Astral a week or so ago. I wanted to use it for a joke a few years ago but this is a much better use for a two letter project name. They agreed to make a donation to the PSF to demonstrate their gratefulness.

Celeo 1y ago
I love this outcome; kudos to you and Astral both!
swyx 1y ago
thanks for not charging obnoxious amounts for package names!
smitty1e 1y ago
ty--thank you
deleted 1y ago
[deleted]
_carljm 1y ago
Yes, thank you for your graciousness and generosity, very much appreciated.
rrszynka 1y ago
nice! what was the planned joke?
- ngoldbaum 1y ago
  Either something about beanie babies or something riffing on "thank you". Couldn't ever make up my mind then basically forgot about it.

urbandw311er 1y ago

It’s like when we hit a new month the quota of “talk about Rust” credits is renewed.

andenacitelli 1y ago
Say what you want, Astral ships impressively fast and their stuff works well. Python has been looking for better tooling for a long time.
rc00 1y ago
The timing of the recent batch of propaganda makes it hard to believe it's not coordinated. I wouldn't suggest paid actors but maybe just an attempt to counter some fairly visible and negative recent takes. The amount of "I love Rust but" comments make it hard to take the commentary seriously too.
- Philpax 1y ago
  Is it really that hard to believe that people like the language and the problems it solves for them?
  - urbandw311er 1y ago
    I think what stands out (and becomes quite tedious) is that most posts on HN don’t tend to include the language choice in the headline. So a typical HN post might be “A new widget that saves times rendering Python code”. Whereas we get this constant barrage of “A new widget that saves times rendering Python code in Rust” with Rust appended to it.
    - urbandw311er 1y ago
      PS: just to explain, the original post title was like this but it has now been modified to remove Rust.

joshdavham 1y ago

Any plans to create an official ty github action? I've been loving the ruff github action.

sestep 1y ago

Is this the same thing as Red Knot?

_carljm 1y ago
Yes, red knot was the internal development code name; ty is the actual name.

robertwt7 1y ago

This will be similar to Typescript I assume? If so I can’t wait to use it!! I cant count how many times I’ve searched for “TS like in Python” since I’ve started working on Python codebase. TS is so awesome that I use it 100% on new projects. Ruff is also very good, but with this, large code base Python will be a breeze to work with

IshKebab 1y ago
You can already use static type annotations in Python and check them with Pyright. This will just make it faster. Also currently the Python IDE support (autocompletion, refactoring, etc.) in VSCode is provided by Pylance which is closed source, so this would provide an open source alternative to that.

briandw 1y ago

Looks good but it has the same issues that i have with mypy. Packages that don't include the type hints blow-up my process. In mypy i've come to terms with strategically ignoring packages or finding a package of type hints. Mypy is runs cleanly on my project but I get >800 errors with TY, mostly things like: lint:unresolved-import: Cannot resolve imported module `pydantic` --> vartia/usr_id.py:4:6 | 2 | from typing import Optional, Any 3 | from enum import Enum 4 | from pydantic import BaseModel, ConfigDict looking forward to the release version.

_carljm 1y ago
The current version can handle importing pydantic without error just fine, but it probably can't find your virtualenv, so it doesn't know what third-party dependencies you have installed. Ty will discover your venv if it is in `.venv` in the project directory; otherwise you can help it out with the `--python` CLI flag.
- alexwaygood 1y ago
  We'll also discover your venv if you: - Activate it manually (`source .venv/bin/activate`, etc.) - Set the `VIRTUAL_ENV` environment variable - Or use a command such as `uv run` or the equivalent from pdm/poetry/hatch to run ty (these project managers usually implicitly set the `VIRTUAL_ENV` variable to point to the project's virtual environment before executing any commands)

pizza 1y ago

Probably not a top priority but it would be really really cool if this thing had solid t-string support from the jump, to the extent that it’s feasible without actually executing code

rowanG077 1y ago

Recently I started a python project and I wanted to do it the "proper" way. mypy + pylint. But even on this small 15-20kloc program these tools are way to slow to do anything in realtime. It takes double digit seconds to have feedback. Way to long for an LSP. I'm honestly appalled the state of affairs is this bad. What the hell do people do with moderately or even large sized code bases?

mil22 1y ago
Pyright + Pylance + Ruff has been rock solid for me on my 100Kloc codebase for more than a year now. I use the VS Code extensions, and Pyright and Ruff are integrated into my pre-commit.
catlover76 1y ago
[dead]
Hasnep 1y ago
They probably use (based)pyright which is much faster than mypy and ruff which is much much much faster than pylint.

Affric 1y ago

See the thing about astral is that they get why Python has been successful in the first place: When it was released it might have been one of the easiest to use languages. The focus on tooling and making the tooling fast has been sharp. Seeing people recommend using non-astral tooling seems nuts at this point.

blibble 1y ago

prior to astral appearing, python's tooling has been beyond terrible, compared to say, Java's astral have now replaced the awful pip with the fantastic uv various awful linters with with the fantastic ruff and now hopefully replacing the terrible type checkers (e.g. mypy) with a good one! I hope they have the pypi backend on their list too, my kingdom for Maven Central in python!

danlamanna 1y ago
> I hope they have the pypi backend on their list too IIRC they have floated the idea of private registries as a commercial offering in the past.
kokada 1y ago
> prior to astral appearing, python's tooling has been beyond terrible, compared to say, Java's I would concur with you if you said Go, Rust, Ruby, or even heck, PHP, but Java is probably the only language that I know that is in a situation even as bad as Python or even worse (at least for me definitely worse, because at least I understand Python tooling enough even when using it only for hobby projects, while I still don't understand Java tooling enough even after working professionally with JVM languages for 7+ years). Java is the only language that I know except Python that has multiple project/package managers (Maven, Gradle, probably even more). It also has no concept of lock files in at least Maven/Gradle, and while resolution dependency in Maven/Gradle is supposed to be deterministic, from my experience it is anything but: just a few weeks ago we had a deployment that failed but worked locally/CI because of dependency resolution somehow pulled different versions of the same library. Fighting dependency hell because different dependencies pull different version constraints is a pain (all Java/JVM projects that I ever worked had some manually pinned dependencies to either fix security issues or to fix broken dependency resolution), and don't even get me in the concept of Uber JARs (that we had to use in previous job because it was the only way to ensure that the dependency tree would be solved correctly; yes maybe it was by incompetence of the team that maintained our shared libraries, but the fact that we even got at that situation is unacceptable). Oh, and also Gradle is "so fun": it is a DSL that has zero discovery (I had IntelliJ IDEA Ultimate and I could still not get it to auto-complete 60% of the time), so I would just blindly try to discover what where the inputs of the functions. The documentation didn't help because the DSL was so dynamic and every project would use it slightly different, so it was really difficult to discover a way to make it work for that specific project (the examples that I would find would be enough different from my current project that 90% of time it wouldn't work without changing something). Python at least has `pyproject.toml` nowadays, and the documentation from PyPA is good enough that you can understand what you want to do after reading it for 10 minutes.

canterburry 1y ago

How about we just stop creating non type safe languages. Would save everyone so much hassle. [bring on the downvotes]

codr7 1y ago
You're begging for it. Not every situation calls for type safe languages, you're projecting a preference.
Hasnep 1y ago
It's a bit late now that python has existed for a couple of decades
- canterburry 1y ago
  How about put it on the roadmap for v4?

ljouhet 1y ago

uv 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 ...`

pt_PT_guy 1y ago
don't forget ruff checker and formatter

tiltowait 1y ago

I've been looking forward to this since the original announcement (and before, really). On the modest codebase I tried it on (14k LOC across 126 files), it runs in 149ms compared to 1.66s in pyright (both run via uvx <tool>). I couldn't get it to play nicely with a poetry project, but it works fine (obviously) in a uv project. Definitely some false-positives, as expected. Interestingly, it seems to hate the `dict()` initializer (e.g. `dict(foo="bar")`).

SOLAR_FIELDS 1y ago
Only one order of magnitude? I thought it would be 2. Isn’t ruff 400x faster than the fastest Python alternative?
- Philpax 1y ago
  A type checker is much more algorithmically bound / difficult to parallelise, but I'm sure there are still wins to be had in the future.

cyounkins 1y ago

How does Astral plan on making money?

preciousoo 1y ago
CI/CD products most likely, or something more futuristic in that line
- nindalf 1y ago
  CI/CD, private repositories, providing hosting. These are the options used by similar companies. But I like that they’re focussing on creating something useful before chasing revenue. Once they’ve got a single tool that provides a consistent dev experience for Python developers and it’s widely adopted they should be able to pursue monetisation easily.
  - anentropic 1y ago
    "Step 3: profit!"
  - Philpax 1y ago
    I think that's a bit optimistic; that's the path every VC-funded tooling company tries to take, and it often doesn't end well; restrictive licenses, hostile forks, early deaths, etc. You need to have some kind of plan ahead of time.

ivanbelenky 1y ago

holy shit this is happening

selfselfgo 1y ago

[dead]

deleted 1y ago

[deleted]

Sarios 1y ago

Perhaps a silly question. Will ty be usable for getting semantical completions / suggestions. Similar to using pyright to get completions based on what's being written.

dcreager 1y ago
We are planning on shipping an LSP front end, and the goal is for that to include code completions. Though to set expectations, they will probably not be that sophisticated on day one. There's a lot of interesting work that we could do here, but it will take time!
- Sarios 1y ago
  You guys take your time and enjoy yourselves :). You have a proven record of making good tools, so if this part takes a while, let it take a while.

no_time 1y ago

Awesome work. What is the business model for these astral tools? It’s a bit of a “waiting for the other shoe to drop” feeling after seeing the VC backing on the company page.

lemontheme 1y ago
From what I’ve gathered (because I had similar concerns), the code is properly open source. In the very worst case, should there ever come a rug pull, it can be forked.
- dcreager 1y ago
  The code is definitely open source from a licensing perspective, but we are also trying to ensure that a healthy community forms around our tools as well. We've been developing ty in the open for the last year or so, and it already includes significant work from external contributors. This is definitely not a project where only Astral-paid engineers can contribute.
  - Tryk 1y ago
    That's cool. So can you elaborate on how your long-term profitability is projected? Of course there would not be too much point in contributing to a project that gets aggressively monetized in the near future.

The-Ludwig 1y ago

If this will be only 50% as awesome as ruff or uv, it will be a future must-have for me.

hamandcheese 1y ago

Not the most fun question, but as I see Astral taking over the python ecosystem, I can't help but wonder: how do y'all plan to make money? It seems like you've taken VC funding, so monetization is inevitable.

renmillar 1y ago
Yes, are they going for enterprise licensing or something similar to JetBrains' approach?
zanie 1y ago
The plan remains the same as when the company was announced (https://astral.sh/blog/announcing-astral-the-company-behind-ruff#whats-next https://astral.sh/blog/announcing-astral-the-company-behind-...) — paid services that build on and integrate with the free tooling.

TeeMassive 1y ago

Glad to see that we have the type-checking equivalent of Ruff!

dhruv3006 1y ago

Great job!