Ty: A fast Python type checker and language server

Post by fastball » Thu, May 08, 2025, 7:10 AM UTC

miki123211 wrote: post #160

mjr00 wrote: post #23

Earlier quoted context omitted.

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

Python is slow for some CPU-intensive operations. There are some extremely CPU-intensive low-level operations that you can easily write in C and expose as a Python API, like what Numpy and Pandas do. You can then write really efficient algorithms in pure Python. As long as those low-level operations are fast, those Python-only algorithms will also be fast. I don't think this is necessarily "cheating" or "just calling…

Post by reubenmorais » Thu, May 08, 2025, 7:16 AM UTC

davedx wrote: post #179

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…

What might, possibly, redeem Python in my eyes as a potential language for making production applications (something that today, it is most certainly not) would be if the type checker worked across the broader ecosystem of common Python packages. For example, as my recent struggles showed, SQLAlchemy breaks `pyright` in all kinds of ways. Compared with how other 'dynamic' ORMs like Prisma interact with types, it's ju…

Post by HelloNurse » Thu, May 08, 2025, 7:31 AM UTC

_carljm wrote: post #30

mjr00 wrote: post #23

Earlier quoted context omitted.

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

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

Post by canterburry » Thu, May 08, 2025, 8:00 AM UTC

Hasnep wrote: post #139

canterburry wrote: post #111

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

It's a bit late now that python has existed for a couple of decades

Post by melodyogonna » Thu, May 08, 2025, 8:20 AM UTC

screye wrote: post #131

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!

Even after all the praise, I'd say they're underrated. Modular.ai raised $100 million to solve tangentially similar problems with python. Astral has already had a much larger impact, while providing better integration with less than 10% of that money.