Live data from Hacker News

Ty: A fast Python type checker and language server

github.com

81–90 of 296 posts

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

#81
post #27

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…

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.

And in the process, they ended up creating an extremely powerful type system that ~nobody outside of that original team can (fully) understand.

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

#83
post #27

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…

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.

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

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

#84
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

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

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

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

#86

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.

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.

I wonder how they'll handle situations like Django, which don't seem expressible via stubs.

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

#87
post #27

Earlier quoted context omitted.

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.

And in the process, they ended up creating an extremely powerful type system that ~nobody outside of that original team can (fully) understand.

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

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

#89

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

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

#90
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?
Post reply on HN