> 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 loading up files, parsing into an AST, etc, it's no surprise that Rust/C/even Go would be an order of magnitude or two faster than Python.

uv and ruff have been fantastic for me. ty is definitely not production ready (I see several bizarre issues on a test codebase, such as claiming `datetime.UTC` doesn't exist) but I trust that Astral will match the "crazy reality" of real Python (which I agree, is very crazy).

> such as claiming `datetime.UTC` doesn't exist)

This is a known issue — we're currently defaulting to a conservative Python version, and `datetime.UTC` really doesn't exist until Python 3.11!

https://docs.python.org/3/library/datetime.html#datetime.UTC

We will probably change the default to "most recent supported Python version", but as mentioned elsewhere, this is very early and we're still working out these kinds of kinks!

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.

How is it condescending in any way? I found it to be a constructive criticism; i.e. useful help.

I don't necessarily read it as condescending, but I do read it as presumptuous. What someone "should" do depends on many things. Maybe, because this is software in alpha stage, they should _not_ focus on this part of the code if it is minor compared to other obligations. Or maybe there are other reasons they've chosen not to do this (as was explained in an above comment).

IMO, a less presumptuous criticism would be phrased like "if you did X then benefits Y would happen", or "if you haven't, consider X", or even (the least presumptuous - make it a conversation!) "have you considered X?", rather than "you should do X".

I see what you mean. Perhaps it was just a "poor" choice of words for whatever reasons. I am sure we can assume he intended it in a way of "have you considered X?".

They said they will default to some newer version, which indicates they are not planning to do this dynamically.

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.

Note that we're not ever spinning up a Python interpreter to run your code, or monitoring an existing running Python process. So we do need some kind of metadata.

But yes, if you have a Python version specified in pyproject.toml, we respect that, and if you have a virtualenv, we can see the Python version that was used to create that. And that's what we use to type-check your code.

The default being discussed here is what we fall back on if that project metadata isn't available.

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

aha makes sense! Yeah it'd be nice if you could divine the intended python version from the uv configuration/`.python-version`. Thanks for all your hard work, looking forward to the full release!

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?

This information is already maintained via `if sys.version_info >= (...):` conditionals in typeshed stubs. I don't think this is important enough to justify maintaining the same information in a duplicate way.

Defaulting is wrong: what is checked is the aggregate of actual user code, standard library for a given Python version and installed packages. It has to be the same environment as when the program is run, leaving conservative approximations (checking types with the oldest supported library versions and hoping newer ones are OK) to the user.

Yes, if you have a Python version specifed in pyproject.toml, for instance, we respect that, and that's what we use to type-check your code. The default being discussed here is what we fall back on if that project metadata isn't available.

Could you check what version of `python` is in the PATH and use that as the default?

mypy is compiled using mypyc. It does not run as Python code.

The semantics of Python makes it problematic to run at speed, it is not just about interpreted vs compiled code. Give the high levels of dynamic behaviors that are allowed, a Jit (like pypy) has a higher chance of getting decent performance if the code has an underlying behavior that can be extracted.

mypy is also written in a style conducive to speed ups when compiling with mypyc

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 disguised C functions." As an example, you can write an efficient linear regression algorithm with Numpy, even though there's nothing in Numpy that supports linear regression specifically, it's just one of the ways a Python programmer can arrange Numpy's low-level primitives. If you invent some new numerical algorithm to solve some esoteric problem in chemistry, you may be able to implement it efficiently in Python too, even if you're literally the first person ever writing it in any language.

The actual problem is that it's hard for people to get an intuition of which Python operations can be made fast and which can't, AST and file manipulation are sadly in the latter group.

That is a confusing way to look at it. Python is slow, C is fast. If your python code is calling functions that were not written in Python (even if it is indirectly thru a library you are using), that is not "pure python".

That works in numerical libraries because you can encapsulate the loops into basic operations that you then lower to C. In a domain like type checking it's not nearly as easy/doable.

> As long as those low-level operations are fast, those Python-only algorithms will also be fast.

Only if you spend more time on the C implementations than on Python. If you have pure Python loops, you'll be slow. You need quite high-level components and minimal Python glue for it to be fast.

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.

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

Parent comment was talking about TypeScript, not Python.

How many people understand the intricacies of any complex language or type system? Though I think one of the great things about TS is that you need to understand none of it in order to do `npm install @types/lodash` and get all the benefits.

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

It's not perfect, but runtime_checkable is a thing https://docs.python.org/3/library/typing.html#typing.runtime...

It doesn't actually preserve typing on the protocol's methods though

What annoys me is that every programmers who wish their favourite language / feature was as popular as Python and they choose to implement it in Python to make Python "better". Python was created as a dynamically typed language. If you want a language with type checking, there are plenty of others available.

Rust devs in particular are on a bend to replace all other languages by stealth, which is both obviously visible and annoying, because they ignore what they don't know about the ecosystem they choose to target. As cool as some of the tools written for Python in Rust are (ruff, uv) they are not a replacement for Python. They don't even solve some annoying problems that we have workarounds for. Sometimes they create new ones. Case in point is uv, which offers custom Docker images. Hello? A package manager is not supposed to determine the base Docker image or Python version for the project. It's a tool, not even an essential one since we have others, so know your place. As much as I appreciate some of the performance gains I do not appreciate the false narratives spread by some Rust devs about the end of Python/JavaScript/Golang based on the fact that Rust allowed them to introduce faster build tools into other programming languages' build chains. Rust community is quickly evolving into the friends you are embarrassed to have, a bit like any JVM-based language that suddenly has a bunch of Enterprise Java guys showing up to a Kotlin party and telling everyone "we can be like Python too...".

This argument doesn't make a whole lot of sense because nothing about type annotations constrains Python code at all. In fact because they're designed to be introspectable they make Python even more dynamic and you can do even crazier stuff than you could before. Type checkers are working very hard to handle the weird code.

Pydantic being so fast because it's written in Rust is a good thing, you can do crazy dynamic (de-)serializations everywhere with very little performance penalty.

> nothing about type annotations constrains Python code at all

Sorry, but this is just not true. Don't get me wrong, I write typed Python 99% of the time (pyright in strict mode, to be precise), but you can't type check every possible construct in the language. By choosing to write typed Python, you're limiting how much of the language you can use. I don't think that's a bad thing, but it can be a problem for untyped codebases trying to adopt typing.

It is literally true. You don't need to run a type checker.

Why do you say that duck typing is simplified structural typing? Its relationship with structural typing is on a different axis. Duck typing is its dynamic-typing counterpart.

Python does support structural typing through protocols introduced in version 3.8. They are documented in https://typing.python.org/en/latest/spec/protocol.html.

As a demo, here is part of https://www.typescriptlang.org/play/typescript/language/stru... translated to Python:

  from dataclasses import dataclass
  from typing import Protocol

  class Globular(Protocol):
      diameter: float

  class Spherical(Protocol):
      diameter: float

  # In Python, we need to define concrete classes that implement the protocols.
  @dataclass
  class Ball:
      diameter: float

  @dataclass
  class Sphere:
      diameter: float

  ball: Globular = Ball(diameter=10)
  sphere: Spherical = Sphere(diameter=20)

  # These assignments work because both types structurally conform to the protocols.
  sphere = ball
  ball = sphere

  class Tubular(Protocol):
      diameter: float
      length: float

  @dataclass
  class Tube:
      diameter: float
      length: float

  tube: Tubular = Tube(diameter=12, length=3)

  tube = ball  # Fail type check.
  ball = tube  # Passes.

This is what Pyright says about it:

  Found 1 error.
  /scratch/structural.py
    /scratch/structural.py:37:8 - error: Type "Ball" is not assignable to declared type "Tubular"
      "Ball" is incompatible with protocol "Tubular"
        "length" is not present (reportAssignmentType)
  1 error, 0 warnings, 0 informations

Edit: And this is ty:

  error: lint:invalid-assignment: Object of type `Ball` is not assignable to `Tubular`
    --> structural.py:37:1
     |
  35 | tube: Tubular = Tube(diameter=12, length=3)
  36 |
  37 | tube = ball  # Fail type check.
     | ^^^^
  38 | ball = tube  # Passes.
     |
  info: `lint:invalid-assignment` is enabled by default
  
  Found 1 diagnostic

I'd go a step further and say that duck typing is more than just structural typing's dynamic counterpart. Because, again, that's confounding two different axes. Dynamic vs static describes when type checking happens and whether types are associated with names or with values. But it doesn't necessarily describe the definition of "type".

The real difference between structural typing and duck typing is that structural typing requires all of a type's declared members to be present for an object to be considered compatible. Duck typing only requires the members that are actually being accessed to be present.

This is definitely more common in dynamic languages, but I'm not aware of any particular reason why that kind of checking couldn't also be done statically.

If I understand correctly, defining the protocol like this forces the implementation classes to have the members as proper fields and disallows properties. If you define `diameter` as a property in the protocol, it supports both:

    from dataclasses import dataclass
    from typing import Protocol

    class Field(Protocol):
        diameter: float


    class Property(Protocol):
        @property
        def diameter(self) -> float: ...

    class Ball:
        @property
        def diameter(self) -> float:
            return 1

    @dataclass
    class Sphere:
        diameter: float

    ball_field: Field = Ball()
    sphere_field: Field = Sphere(diameter=20)

    ball_prop: Property = Ball()
    sphere_prop: Property = Sphere(diameter=20)

Pyright output:

    /Users/italo/dev/paper-hypergraph/t.py
      /Users/italo/dev/paper-hypergraph/t.py:27:21 - error: Type "Ball" is not assignable to declared type "Field"
        "Ball" is incompatible with protocol "Field"
          "diameter" is invariant because it is mutable
          "diameter" is an incompatible type
            "property" is not assignable to "float" (reportAssignmentType)
    1 error, 0 warnings, 0 information 

That is to say, I find Python's support for structural typing to be limited in practice.

It's not mypy issue. Comparing to TS python typehints (spec wise) are a joke. It's started as bolted on adhoc solution and evolved quite chaotically. For example [1]. TS doesn't require a special decorator (sic!) to make your custom classes to be picked up by type checkers.

Or how make a wrapper function with args and kwargs to pass through?

[1]: https://docs.python.org/3/library/typing.html#typing.datacla...

The dataclass decorator isn't there to make the type checkers understand the class. Its main purpose is to automatically implement trivial methods like the constructor, equality, repr, etc. The type hints make this more convenient, but something similar already existed with attrs.

It's literally stated in the PEP: https://peps.python.org/pep-0681/

Also: https://github.com/python/mypy/blob/501a07b45af8e44eda665e53...

Also did you know mypy ignores typing of class decorators? You simply can't return a different type other than type[thisclass].

Even Typescript is rewriting their compiler in Go. I think that the bottleneck is _actually_ the language sometimes.

(And uv and ruff have basically proved that at this point)

through algorithmic improvements can also go a long way and if you are one of the first type checker which have to figure out the mess the python type annotation system is you will vast a lot of time on figuring that out instead of refactoring it's architecture to allow for algorithmic improvements

which brings us to another python issue, python is quite bad at such huge refactoring even with type checkers

but yeah python is by far the slowest widely used language, and for some use cases you can side step it by placing most hot code in C++/Rust extension modules, (or don't care because you are much much more network latency bound) but a type checker probably doesn't belong into that category

> I wish more python tooling

And not directly related, but I wish more python modules did proper checks with Valgrind before shipping.

The CPython API is such a dumpster fire, even writing very simple modules the reference counting is very difficult to do correctly. The majority of python modules written in C are probably leaking memory somewhere but nobody knows.

My problem is that debugging a segfault in a Python system is impossible because of all the noise generated by Python modules that never bothered to clean up their Valgrind output.

Some tricks that worked for me in the past:

1. use rr for debugging your binary wheel, you can set up watchpoints, and reverse step/continue from the segfault.

2. compile and run your wheel with sanitizers (ASAN, UBSAN).

I rarely use valgrind so I can't comment on that.

>The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code.

Nah, that's just part of the parade of excuses that comes out any time existing software solutions get smoked by a newcomer in performance, or when existing software gets more slow and bloated.

Here's one of many examples:

https://m.youtube.com/watch?v=GC-0tCy4P1U&pp=0gcJCdgAo7VqN5t...

Sure, but so far this has been a true criticism of every python type checker that isnt mypy that is production ready today

the thing is most (all) of the type checkers including e.g. mypy _do not_ support most crazy python ...

not because they don't want to or because it's to slow

but because it's not really viable without fully executing module loading in a sandbox, which might seem viable until you realize that you still need to type check `__main__` modules etc. and that its a common trend in python to do configs by loading python modules and grabbing the module locals as keys of the config or loading some things might actually idk. initialize a GPU driver :sob: So it's kinda 100% guaranteed not possible to do fully correct type checking for all project :smh:

But also python is one of the slowest popular languages (and with a large margin to any not also "one of slowest" languages). Only by moving hot code into C++/Rust is it fast, which often is good enough, but a type checker is exactly this kind of software where this approach stops working.

Python's static checking capabilities could significantly improve both tracing and compilation efficiency. The language features that currently limit type checkers are likely the same ones making efficient compilation difficult. Perhaps we'll eventually see a Python 3.40 with complete JIT compilation, functioning similarly to Julia but retaining Python's extensive ecosystem that makes it essential in certain domains.

Can mypy type check SQLAlchemy somehow? That's what caused me to give up on Python type checking recently

SQLAlchemy 2.x has direct support for mypy, it works out of the box, no longer needing mypy plugins. Many things in SQLAlchemy as are still dynamic and can't be type checked, but the native support works great where it can.

I’ll give that a try. Thanks

I also mentioned this up-thread, but https://pypi.org/project/django-types/ is compatible with pyright without plugins, so it should theoretically work with ty. It's not quite as good as the mypy-django plugin but it still catches a lot.