Comment by aleksanb

Comment by aleksanb a day ago

11 replies

To repeat an earlier comment of mine from the launch of uv on hn (tl; dr: these new type checkers never support django):

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 the constructs we think you SHOULD be using".

tasn a day ago

1. Maybe it's time to drop the crazy runtime generation and have something statically discoverable, or at least a way to annotate the typing statically.

2. Astral indicated already they plan to just add direct support for Django and other popular languages.

3. As people replied to similar comments on the previous threads (maybe to you?): that's not why ty is fast and why mypy is slow. It's also an easy claim to disprove: run both without plugins and you'll see ty is still 100x+ faster.

  • WhyNotHugo a day ago

    > 1. Maybe it's time to drop the crazy runtime generation and have something statically discoverable, or at least a way to annotate the typing statically.

    That, and duck typing, are one of the biggest things that make Python what it is. If I have to drop all that for type checking and rewrite my code, why would I rewrite it in Python?

    • dontlaugh a day ago

      Having used Python for many years, it’s the least interesting aspect of the language. Almost all such tricks can be done with compile time meta programming, often even without API changes.

      • mixmastamyk a day ago

        I'd like to read a blog post on this subject, if anyone knows one.

        • dontlaugh 14 hours ago

          I don’t know about a blog post, but I mean the obvious stuff like codegen, generics/templates or macros to achieve the same things Python does by being dynamic.

          Almost no one actually uses eval/exec.

    • rixed 16 hours ago

      Not only duck types (ie structural type hierarchies) can be statically verified but they can be statically infered as well, as demonstrated for instance by ocaml since 1996.

      "Here is a nickel, kid, get yourself a better programming language" :-p

zem 5 hours ago

these are two different issues. supporting django involves adding a special-case module that essentially replicates its code generation and then adds that to the type-level view of the code. pyrefly or ty could do that and would still be just as fast. my guess is that once they have the basic python type checker as close to 100% as they can, they will start looking at custom modules for various popular metaprogramming libraries, or add enough of a plugin framework that the community can contribute them.

source: spent several years working on a python type checker

adsharma a day ago

The problem is not with the type checkers.

https://code.djangoproject.com/ticket/32759

Similar (but lesser) problems exist with pydantic and sqlmodel. They're both fine projects except for:

https://www.reddit.com/r/Python/comments/1i5atpy/fquery_meet...

This is a long winded way of saying type checkers will deal with:

  @sqlmodel
  @pydantic
  @dataclass
  class MyModel:
    name: str

a lot better. Move what doesn't fit here to dataclass metadata.
fulafel a day ago

TS has the luxury of being its own distinct language, defining its own semantics and having its own compiler. You could have something like that targeting Python.

insane_dreamer a day ago

The only type checker that fully works (meaning it successfully performs the necessary type inference all for inherited objects) for our large and highly modular python codebase, is Pycharm (I'm guessing it's their own custom tool from the ground up? Not really sure, actually.)