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

41–50 of 296 posts

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

#41

Post by amelius »

aleksanb wrote: post #20

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

> I wish more python tooling

And not directly related, but I wish more python modules did proper checks with Valgrind before shipping.

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

#43

Post by 12_throw_away »

zanie wrote: post #28

: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. Sta…

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

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

#45

Post by digdugdirk »

zanie wrote: post #28

: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. Sta…

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!

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

#46

Post by TheTaytay »

aleksanb wrote: post #20

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

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)

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

#49

Post by dcreager »

digdugdirk wrote: post #45
zanie wrote: post #28

: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. Sta…

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

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

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

#50

Post by [deleted] »

mjr00 wrote: post #23
aleksanb wrote: post #20

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

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

[deleted]
Post reply on HN