7 ms·

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 i

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

fulafel 1y 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.
tasn 1y 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 1y 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 1y 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 1y ago
      I'd like to read a blog post on this subject, if anyone knows one.
      - dontlaugh 1y 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 1y 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
deleted 1y ago
[deleted]
insane_dreamer 1y 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.)
adsharma 1y ago
The problem is not with the type checkers. https://code.djangoproject.com/ticket/32759 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_meets_sqlmodel/ 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.
zem 1y 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

fulafel 1y 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.

tasn 1y 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 1y 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 1y 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 1y ago
    I'd like to read a blog post on this subject, if anyone knows one.
    - dontlaugh 1y 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 1y 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

deleted 1y ago

[deleted]

insane_dreamer 1y 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.)

adsharma 1y ago

The problem is not with the type checkers. https://code.djangoproject.com/ticket/32759 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_meets_sqlmodel/ 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.

zem 1y 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