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

231–240 of 296 posts

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

#231

Post by diggan »

simonw wrote: post #19
Handprint4469 wrote: post #4

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

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

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.

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

#232

Post by Philpax »

SOLAR_FIELDS wrote: post #173
tiltowait wrote: post #133

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 ). 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()` initia…

Only one order of magnitude? I thought it would be 2. Isn’t ruff 400x faster than the fastest Python alternative?

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.

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

#233

Post by zarathustreal »

lacasito25 wrote: post #217
zo1 wrote: post #187

Earlier quoted context omitted.

You should be doing this dynamically based on the version of python you are running against, so that you don't have to hardcode or make such "conservative" choices by hand.

I think they probably know that, this is alpha software, no need to be condescending.

Criticism isn’t necessarily condescending. “You should be doing x because y” is just a plain assertion, it doesn’t imply any moral judgement or opinion of the author.

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

#234

Post by Philpax »

nindalf wrote: post #177
preciousoo wrote: post #146

Earlier quoted context omitted.

CI/CD products most likely, or something more futuristic in that line

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.

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.

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

#236

Post by jychang »

_carljm wrote: post #176
miki123211 wrote: post #161

Earlier quoted context omitted.

I realize this might be hard from a technical / architecture standpoint, but it would be great if "does not exist" and "does not exist in this version of Python " were two different errors. If I saw something like "datetime.UTC doesn't exist", I'd immediately think "wait, was that datetime.utc", not "ooh it got added in 3.11, I need to change my Python version"

I agree that would be nice; probably not near the top of our list right now (and not trivial to implement), but it makes sense. Thanks for the suggestion.

Nontrivial way to do it is dynamically scan the python 3.12 namespace, and add these warnings.

Is there any big downside to do it the boring way, hardcode a list and compare the error to the list?

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

#237

Post by reubenmorais »

Spivak wrote: post #214
reubenmorais wrote: post #203

Earlier quoted context omitted.

This is a weakness of the Python typing system and not necessarily of individual typecheckers. Pyright has a policy of only implementing what's standardized, and the Python type system is simply inadequate to annotate most real world Python code out there. It's been years now and something as basic as properly typing kwargs is still not supported. Ty could solve this if they rebel and decide to ignore the Python typi…

> properly typing kwargs is still not supported. I've been typing them with TypedDict for a while now and it's been fine. What can't you do?

Two examples that come to mind are: https://discuss.python.org/t/pep-692-using-typeddict-for-mor...

and: https://github.com/python/typing/issues/1252

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

#238

Post by Nab443 »

pjmlp wrote: post #218
Spivak wrote: post #215

Earlier quoted context omitted.

Instagram I think would like a word with you on its viability for production.

Maybe you should first investigate all the gimmicks they had to do, between amount of servers they had to ramp up burning needless budget, rewriting code into C and C++ libraries, Go or whatever else they ended up adding, before doing such statements. https://stackshare.io/instagram/instagram

Any other link to share about that? The stackshare url does not even mention anything related.

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

#240

Post by shiandow »

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…

CPU intensive is not quite the right metric. What python is slow at is all the extra administration that comes with basic stuff like accessing attributes and function calls.

This gives somewhat counterintuitive results where declaring and summing a whole list of integers in memory can be faster than a simple for loop with an iterator.

But yeah writing stuff in a different (compiled) language is often better if that means the python interpreter doesn't need to go through as many steps.

Post reply on HN