I use stub files and mypy, but have concerns about behavior.

Thought the point is to move the static type checking stuff into a separate file. This makes the code much easier to read.

1. When a particular stub file becomes out of date, contents don't reflect what's going on in the code, there is no warning.

2. inner functions are ignored.

3. a functions contents are ignored.

Reluctant to use a library running node (gh actions aside) or Rust. My opinion is speed and correctness are insufficient arguments to introduce another tech stack. If something breaks, suddenly the onus is on me to understand why. That's complicated if the additional tech stack is in a coding language i'm unfamiliar with.

This takes out: ruff, uv, and pyright. And whatever else comes out.

Have seven published python packages.

Trying to be open minded. Please layout other arguments why should be open to utilizing other tech stacks.

I think your last sentence hits the nail on the head. It's not perfect but it's good enough. There are some pains and edge cases but it still makes a night and day difference. This is my experience after introducing typing to the entire codebase in my work project over the course of last year.

In my experience, it’s a manageable trade off.

You allow for Python “magic” at the cost of type safety. Or you forgo magic for types, and the resiliency that comes with it.

Day to day, you don’t need magic. With good application of hinting you can stop many bugs before they appear.

When you do need magic, you can usually construct it to work within the type system, or at the very least easily ringfence the tainted typeless code the magic introduced.

The sync/async contradiction is much worse to wrangle.

How powerful do you want it? Python's type system is actually pretty good already and relatively sound when checked with Pyright (not Mypy though).

It's not Typescript-level, but it's better than e.g. Java or C++.

The main problem is Python developers writing code that can't be statically type checked. E.g. using magically generate method names via __dict__ or whatever (I think lxml does that).

i don't believe it's possible either. For example the tree walker of the ast module takes the node passed to it, checks its type, gets its name, then looks for the method with that dynamically looked up name in your implementation of the tree walker and if it does (the user might not have implemented a visit method for that type of node), calls it and passes the node to it. All of this at runtime.

IIUC, copying over RustPython parser is an interesting detail, but that change happened earlier (2023!) when they were building Ruff, so it is old news. This piece of code called red-knot seems to be mostly original work, as far as I can tell.

https://github.com/astral-sh/ruff/issues?q=is%3Aopen+label%3Ared-knot+sort%3Acreated-asc

python already is that comic, to the T. https://chriswarrick.com/blog/2023/01/15/how-to-improve-python-packaging/

Well, Astral as an history of managing to build tools that are actually very very clearly more usable than the pile of poop that Python ecosystem is 😅

Pyright is very good. The rest are worthless though.

I don’t like the current landscape of python type checkers.

I figure that Python itself is at the bottom of this. It simply wasn't designed for static types. Mypy is still of some use but if you want a statically typed language, trying to graft a type system onto a unityped language hasn't worked out well as far as I know. See also: the Erlang dialyzer, Typed Racket, and whatever that Clojure extension is called. Even Scala has its problems because the JVM has its own type system that isn't that great a fit for Scala.

Also, why Rust as the implementation language? Just for speed? It seems a shame to not use Python/PyPy.

Yes. It's a frontend for twitter, based on nitter.

It's similar to invidious for youtube.

Just in case that's a genuine question, the reasons people like static types are:

1. Catch more bugs.
2. Catches bugs earlier (while you are writing the code). This is sometimes called "shift left".
3. Fewer tests needed.
4. Code is easier to understand.
5. Code is easier to navigate.
6. Refactoring is much easier.
7. Development speed is faster (due to the above points).

Often people say it slows development down but it's actually the opposite. Especially for large projects or ones involving multiple people.

The only downside really is that sometimes the types can get more complicated than they're worth, but in that case you have an escape hatch via the Any type.