Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ty: A fast Python type checker and language server

github.com

Post reply on HN
Print view View original

121–130 of 296 posts

Re: Ty: A fast Python type checker and language server

#121

Post by geekraver »

dathinab wrote: post #103
bjourne wrote: post #76

Earlier quoted context omitted.

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

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…

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

Re: Ty: A fast Python type checker and language server

#122

Post by danlamanna »

blibble wrote: post #110

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!

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

Re: Ty: A fast Python type checker and language server

#123

Post by zem »

the_mitsuhiko wrote: post #26
andenacitelli wrote: post #18

Earlier quoted context omitted.

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.

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.

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.

Re: Ty: A fast Python type checker and language server

#124

Post by tyrion »

dcreager wrote: post #72
12_throw_away wrote: post #43

Earlier quoted context omitted.

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

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 di…

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.

Re: Ty: A fast Python type checker and language server

#125

Post by kokada »

blibble wrote: post #110

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!

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

Re: Ty: A fast Python type checker and language server

#126

Post by rexledesma »

maxloh wrote: post #69
rexledesma wrote: post #58

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.

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.

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.

Re: Ty: A fast Python type checker and language server

#127

Post by _carljm »

scosman wrote: post #89
Handprint4469 wrote: post #4

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

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

There's a good chance many of the errors we emit are incorrect, at this stage. Lots to do still!

Re: Ty: A fast Python type checker and language server

#128

Post by _carljm »

akdor1154 wrote: post #120
nickagliano wrote: post #10

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.

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…

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.

Re: Ty: A fast Python type checker and language server

#129

Post by _carljm »

darkteflon wrote: post #62
dcreager wrote: post #51

Earlier quoted context omitted.

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.

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.

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.

Re: Ty: A fast Python type checker and language server

#130

Post by bb88 »

dcreager wrote: post #60
digdugdirk wrote: post #53

Earlier quoted context omitted.

Fingers crossed this isn't a joke.

Well, it is a joke...but that said, we're hosting a happy hour which is kinda similar! https://partiful.com/e/Dcrv6XA8PjWTK5Zhw8yr

I'm looking forward to talking with you guys.
Post reply on HN