[HN Gopher] Ty: A fast Python type checker and language server
___________________________________________________________________
Ty: A fast Python type checker and language server
Author : arathore
Score : 442 points
Date : 2025-05-07 17:32 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tmvphil wrote:
| 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 wrote:
| 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
| nine_k wrote:
| 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 wrote:
| 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
| dathinab wrote:
| 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 wrote:
| 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/718...
| insane_dreamer wrote:
| in my experience pyright is unable to infer many inherited
| object types (compared to PyCharm's type inference)
| 0xFF0123 wrote:
| Pyright is incredibly slow in my experience, I've seen it
| take over a minute on complex codebases
| js2 wrote:
| 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 wrote:
| > 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 wrote:
| (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 wrote:
| 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 wrote:
| 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 wrote:
| If you have uv installed, you can test it without installing by
| running: uvx ty check
| wdroz wrote:
| You can also install it "globally" for your user with:
| uv tool install ty
|
| Then you can use it anywhere ty check
| heavyset_go wrote:
| Can also do uv tool run ty
|
| If your $PATH sucks
| simonw wrote:
| 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/a13e1720b03e23783ae668eca7f6f...
|
| Adding "time uvx ty check" shows it took: uvx
| ty check 0.18s user 0.07s system 228% cpu 0.109 total
| alexmolas wrote:
| how does it compare against mypy? is it much faster?
| IshKebab wrote:
| How does it compare against _Pyright_. Pyright is the gold
| standard of Python type checking currently. Mypy is slower
| and buggier.
| Redoubts wrote:
| Mypy is also able to check things that are inexpressible
| with stubs, among other things
| scosman wrote:
| 0.2s on ty compared to 4.7s on pyright. Not even close.
| simonw wrote:
| In the same folder: time uvx mypy .
|
| Result: uvx mypy . 0.46s user 0.09s
| system 74% cpu 0.740 total
|
| So ty is about 7x faster - but remember ty is still in
| development and may not catch the same errors / report
| false errors, so it's not a fair comparison yet.
| hauntsaninja wrote:
| Note that `uvx mypy` may give you inaccurate timings on
| macOS. The antivirus in macOS goes a little crazy the
| first time it executes a mypyc compiled program.
| scosman wrote:
| Found 275 diagnostics
|
| 0.56s user 0.14s system 302% cpu 0.231 total
|
| Damn that's fast. And zero issues in this project with pyright
| so curious that these are...
| _carljm wrote:
| There's a good chance many of the errors we emit are
| incorrect, at this stage. Lots to do still!
| throwaway63467 wrote:
| 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 wrote:
| There's Pyrefly if you wanna check it out:
| https://github.com/facebook/pyrefly
| drcongo wrote:
| I've been looking forward to this for what seems like an age.
| codydkdc wrote:
| how long is an age?
| tough wrote:
| a year (probably)?
| drewcoo wrote:
| 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/
| GuinansEyebrows wrote:
| in the tolkien legendarium they may be over 3000 years.
| amelius wrote:
| We're living in the information age. Not sure when or what
| the next age will be, but you get the idea.
| arijun wrote:
| Pretty sure we've already made it to the disinformation
| age.
| nickagliano wrote:
| 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 wrote:
| Astral announced it last year I think, so it's been a long time
| coming.
| emptysea wrote:
| Also interesting, pyrefly uses Ruff's parser!
|
| https://github.com/facebook/pyrefly/blob/a8626110da034f8e513...
| ipsum2 wrote:
| 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 wrote:
| > 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
| zem wrote:
| language tooling is a sweet spot for rust, for sure.
| akdor1154 wrote:
| 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.)
| _carljm wrote:
| Yes, we've talked; I know a number of the pyrefly devs well.
| Ty had already been months in development when pyrefly
| development started. We discussed collaboration, but they
| decided they needed to do their own thing in order to move
| quickly and ensure it would serve their needs, which is
| totally reasonable.
| kodablah wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I mean that kind of code exists; things like _attrs_ are
| too magical otherwise
| zem wrote:
| 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 wrote:
| Charlie already said in a podcast
| (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.
| WhyNotHugo wrote:
| I wonder how they'll handle situations like Django, which
| don't seem expressible via stubs.
| dathinab wrote:
| not specific to just your answer but why do people mention
| ruff?
|
| Ruff is a linter which (intentionally) does close to no type
| checking.
|
| So you pretty much have to pair it up with a type check to
| get any even just half way decent static code analysis.
| aleksanb wrote:
| 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 wrote:
| > 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 wrote:
| (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 wrote:
| 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!
| dcreager wrote:
| > such as claiming `datetime.UTC` doesn't exist)
|
| This is a known issue -- we're currently defaulting to a
| conservative Python version, and `datetime.UTC` really
| doesn't exist until Python 3.11!
|
| https://docs.python.org/3/library/datetime.html#datetime.UTC
|
| We will probably change the default to "most recent supported
| Python version", but as mentioned elsewhere, this is very
| early and we're still working out these kinds of kinks!
| johnfn wrote:
| In defense of mypy et al, Typescript had some of the greatest
| minds of our generation working for a decade+ on properly
| typing every insane form found in every random Javascript file.
| Microsoft has funded a team of great developers to hammer away
| at every obscure edge case imaginable. No other python checker
| can compare to the resources that TS had.
| smithkl42 wrote:
| And in the process, they ended up creating an extremely
| powerful type system that ~nobody outside of that original
| team can (fully) understand.
| dathinab wrote:
| IMHO they created type annotations, not a type system
|
| and how you use the type annotations to indicate a type
| system is inconsistent and incomplete (e.g. NoneType vs.
| None for inconsistency and a lot of mess related to
| mataclasses (e.g. Enum) and supporting type annotations for
| them for incomplete)
|
| the fact that even today something as fundamental as enums
| have issues with type checking _which are not just type
| checker incompetence_ is I think a good way to highlight
| what mess it is
|
| or that `Annotated[]` was only added in 3.9 and has a ton
| of visual overhead even through its essential for a lot of
| clean definitions in modern python code (where for
| backwards compatibility there is often some other way,
| which can be de-facto wrongly typed but shouldn't be type
| linted, have fun type checkers).
| simonw wrote:
| Parent comment was talking about TypeScript, not Python.
| dathinab wrote:
| It's even worse (for python).
|
| TS might transpile to JS and can always be split into a js
| and type annotation file but is it's own language developed
| in tandem with the type check based on a holistisch approach
| to find how to type check then and then put it into the
| syntax and type checker.
|
| Thats not true for python at all.
|
| Python types where added as annotations to the language many
| years ago, but not in a holistic approach but in simplistic
| approach only adding some fundamental support and then
| extended bit by bit over the years (and not always
| consistently).
|
| Furthermore this annotations are not limited to type checking
| which can confuse a type checker (through Annotated helps a
| lot, but is also verbose, wonder how long until there is a
| "Annotated" short syntax e.g. by impl @ on type or similar).
|
| Basically what the type annotation feature was initially
| intended to be and what it is now differ quite a bit (dump
| example `list` vs. `List`, `Annotated` etc.).
|
| This is made worse that a bunch of "magic" is deeply rooted
| in python, e.g. sub-classing `Enum`. Sure you have that in JS
| too, and it also doesn't work that well in TS (if you don't
| add annotation on the dynamically produced type).
|
| Lastly TS is structurally typed, which allows handling a
| bunch of dynamic typing edge cases, while Python is, well,
| in-between. Duck-typing is (simplified) structural typing but
| `isinstance` is a common thing in Python and is nominal
| typing...
|
| So yeah it's a mess in python and to make it worse there
| bunch of annoyances related to ambiguity or to many ways how
| to do a thing (e.g. re-exports+private modules, you can do
| that common coding pattern, but it sucks badly).
| HideousKojima wrote:
| >The way these type checkers get fast is usually by not
| supporting the crazy rich reality of realworld python code.
|
| Nah, that's just part of the parade of excuses that comes out
| any time existing software solutions get smoked by a newcomer
| in performance, or when existing software gets more slow and
| bloated.
|
| Here's one of many examples:
|
| https://m.youtube.com/watch?v=GC-0tCy4P1U&pp=0gcJCdgAo7VqN5t...
| Redoubts wrote:
| Sure, but so far this has been a true criticism of every
| python type checker that isnt mypy that is production ready
| today
| dathinab wrote:
| the thing is most (all) of the type checkers including e.g.
| mypy _do not_ support most crazy python ...
|
| not because they don't want to or because it's to slow
|
| but because it's not really viable without fully executing
| module loading in a sandbox, which might seem viable until
| you realize that you still need to type check `__main__`
| modules etc. and that its a common trend in python to do
| configs by loading python modules and grabbing the module
| locals as keys of the config or loading some things might
| actually idk. initialize a GPU driver :sob: So it's kinda
| 100% guaranteed not possible to do fully correct type
| checking for all project :smh:
|
| But also python is one of the slowest popular languages (and
| with a large margin to any not also "one of slowest"
| languages). Only by moving hot code into C++/Rust is it fast,
| which often is good enough, but a type checker is exactly
| this kind of software where this approach stops working.
| amelius wrote:
| > I wish more python tooling
|
| And not directly related, but I wish more python modules did
| proper checks with Valgrind before shipping.
| TheTaytay wrote:
| Even Typescript is rewriting their compiler in Go. I think that
| the bottleneck is _actually_ the language sometimes.
|
| (And uv and ruff have basically proved that at this point)
| dathinab wrote:
| through algorithmic improvements can also go a long way and
| if you are one of the first type checker which have to figure
| out the mess the python type annotation system is you will
| vast a lot of time on figuring that out instead of
| refactoring it's architecture to allow for algorithmic
| improvements
|
| which brings us to another python issue, python is quite bad
| at such huge refactoring even with type checkers
|
| but yeah python is by far the slowest widely used language,
| and for some use cases you can side step it by placing most
| hot code in C++/Rust extension modules, (or don't care
| because you are much much more network latency bound) but a
| type checker probably doesn't belong into that category
| krupan wrote:
| Have these guys figured out how to make money yet?
| dcreager wrote:
| We're going to set up a lemonade stand in the main hall at
| PyCon next week
| digdugdirk wrote:
| Fingers crossed this isn't a joke.
| dcreager wrote:
| Well, it _is_ a joke...but that said, we 're hosting a
| happy hour which is _kinda_ similar!
|
| https://partiful.com/e/Dcrv6XA8PjWTK5Zhw8yr
| bb88 wrote:
| I'm looking forward to talking with you guys.
| all2 wrote:
| This might actually be a decent business model. Sell hard
| goods to fund your habit of making excellent software tools.
| joshdavham wrote:
| I'm curious to see what Astral will cook up! I assume they'll
| probably eventually create some sort of paid devtool service.
|
| With that being said, the worst case scenario is that they go
| caput, but that still leaves the python community with a set of
| incredible new rust-based tools. So definitely a net win for
| the python community either way!
| __MatrixMan__ wrote:
| If they're making our lives better, perhaps the question is
| whether we've figured out how to pay them yet.
| zanie wrote:
| :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 wrote:
| 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 wrote:
| 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 wrote:
| +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 wrote:
| 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.)
| dcreager wrote:
| At least for the moment, we aren't planning on a plugin
| architecture. We do recognize that there are some popular
| libraries and code patterns that aren't easily (or at all)
| typeable with the current state of the typing spec. We feel
| it would be more useful to help drive changes to the typing
| spec where we can, so that other type checkers can also
| benefit; and/or implement workarounds for the most popular
| libraries directly in ty, so that a library author doesn't
| have to rely on their downstream consumers installing a
| particular set of plugins to get good type-checker results.
|
| (It's also more difficult to support plugins effectively in a
| type checker like ty, than in a linter like ruff, since any
| non-trivial use case would likely require deep changes to how
| we represent types and how we implement type inference.
| That's not something that lends itself to a couple of simple
| hook extension points.)
| tyrion wrote:
| Helping improve the spec and all is great, but being 100%
| honest, as a user, I would rather have a type checker I can
| bend to my needs. As you said, some code patterns in a
| dynamic language like Python are difficult, or even
| impossible, to type-check without custom code. Type
| checkers are becoming more popular than ever, and this
| implicitly means that these code patterns are are going to
| be discouraged. On one hand, I believe the dynamism of
| Python is core to the language. On the other, I would never
| want to write any collaborative piece of software without a
| type checker anymore. Therefore, to get the benefits of a
| type checker, I am occasionally forced to write worse code
| just to please it.
|
| Considering how fast uv and ruff took off, I am sure you
| are aware of the impact your project could have. I
| understand that supporting plugins is hard. However, if you
| are considering adding support for some popular libraries,
| IMHO, it would be really beneficial for the community if
| you could evaluate the feasibility of implementing things
| in a somewhat generic way, which could be then maybe
| leveraged by third-party authors.
|
| In any case, thanks for all the amazing work.
| danlamanna wrote:
| I also asked this question here: https://github.com/astral-
| sh/ruff/discussions/15149#discussi....
| digdugdirk wrote:
| Cool! Out of curiosity, what's the bedrock that's used to
| determine what the fundamental python AST objects are? I'm
| wondering what the "single source of truth" is, if you will.
|
| Is this all based off a spec that python provides? If so, what
| does that look like?
|
| Or do you "recode" the python language in rust, then use rust
| features to parse the python files?
|
| Regardless of how it's done - This is a really fascinating
| project, and I'm really glad you guys are doing it!
| dcreager wrote:
| There is a formal grammar defined in the CPython repo,
| implemented in a language called ASDL:
|
| https://github.com/python/cpython/blob/main/Parser/Python.as.
| ..
|
| ty uses the same AST and parser as ruff. We don't use the
| ASDL grammar directly, because we store a few syntax nodes
| differently internally than how they're represented upstream.
| Our parser is hand-written in Rust. At first, our AST was
| also entirely hand-written, though we're moving in the
| direction of auto-generating more of it from a declarative
| grammar.
|
| https://github.com/astral-sh/ruff/issues/15655
|
| https://github.com/astral-
| sh/ruff/tree/main/crates/ruff_pyth...
|
| https://github.com/astral-
| sh/ruff/blob/main/crates/ruff_pyth...
| zanie wrote:
| ditto! but we gave impressively non-overlapping answers
| zanie wrote:
| As in, how are we parsing the Python code into an AST?
|
| CPython uses a generated parser. The grammar is defined in ht
| tps://github.com/python/cpython/blob/main/Grammar/python.g...
| which is used to generate the specification at
| https://docs.python.org/3/reference/grammar.html#full-
| gramma...
|
| We use a hand-written parser, in Rust, based on the
| specification. We've written that previously at
| https://astral.sh/blog/ruff-v0.4.0#a-hand-written-parser
| BewareTheYiga wrote:
| For pre-alpha software it's working fantastic for my project. I
| thought I type annotated it well, but Ty had quite a lot of
| feedback for me. Great job and I can't wait until this is
| released.
| IshKebab wrote:
| Had you checked it with Pyright previously?
| BewareTheYiga wrote:
| I've only used Pylance standard type checking in vscode. I
| have not used pyright as a stand alone package.
| ZiiS wrote:
| Pointlessmy anal; but 0.0.0a6 is very strongly indicative of
| the sixth alpha release. Pre-alpha are much better as .dev
| releases.
| usr9012809 wrote:
| > Pre-alpha are much better as .dev releases.
|
| No, they are correctly using semantic versioning to indicate
| pre-alpha releases. https://github.com/astral-sh/ty/releases
| https://semver.org/
| kstrauser wrote:
| Python doesn't use plain semver:
| https://peps.python.org/pep-0440/
| simlevesque wrote:
| I installed it in VSCode and removed Mypy, I haven't looked back:
| https://marketplace.visualstudio.com/items/?itemName=astral-...
| tayo42 wrote:
| Curious why so many people want to implement type checkers for
| python? What problems are being solved that aren't covered
| already?
| simonw wrote:
| Speed.
| alexwaygood wrote:
| 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 wrote:
| The ones that are around are slow, and working with untyped
| Python is a pain in large codebases
| dathinab wrote:
| 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 wrote:
| Does it support go to definition and other lsp features?
| dcreager wrote:
| 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), it's
| still very early days for ty, so we don't have concrete release
| announcements for that yet.
| darkteflon wrote:
| 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 wrote:
| 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.
| cristea wrote:
| Will it support Django stubs? Only blocker for my company to
| switch
| joejoo wrote:
| Astral killing it with the Python tooling.
| rexledesma wrote:
| 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 wrote:
| You should try basedpyright:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I love this outcome; kudos to you and Astral both!
| urbandw311er wrote:
| It's like when we hit a new month the quota of "talk about Rust"
| credits is renewed.
| joshdavham wrote:
| Any plans to create an official ty github action? I've been
| loving the ruff github action.
| sestep wrote:
| Is this the same thing as Red Knot?
| _carljm wrote:
| Yes, red knot was the internal development code name; ty is the
| actual name.
| robertwt7 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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?
| Affric wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| How about we just stop creating non type safe languages. Would
| save everyone so much hassle.
|
| [bring on the downvotes]
| ljouhet wrote:
| 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 ...`
___________________________________________________________________
(page generated 2025-05-07 23:00 UTC)