Hacker News Reader

Comment by MapleWalnut | Hacker News Reader

I've used mypy and pyright. Mypy generally "just works" for all the Python idioms I use, while pyright is less reliable.

Pyright's VSCode integration, Pylance, provides a great auto complete experience. So I use Pyright for autocomplete in VSCode and mypy for type checking.

View on HN

Last I checked, mypy struggled to represent recursive types. Think `JSON = Union[None, bool, str, float, int, List['JSON'], Dict[str, 'JSON']`. That's a bummer because recursive data types are darn handy.

Worse, importing third party packages often fails silently and when you can get error messages they tend to be completely inactionable (I recall one error message which linked to a web page that had lots of details and workarounds for fixing other problems, but none of which solved the error itself).

Figuring out how to distribute my own type annotations was similarly painful. IIRC, you have to drop a specially-named file into a particular directory and this is all undocumented save for a dense PEP and the error messages are unsurprisingly terrible. All of these things are actionable, but the progress seems slow (these have been among my top grievances since the project debuted, so the maintainers and I have different priorities, clearly).

The problems for which I'm less optimistic tend to revolve around shoehorning typing into existing Python syntax--e.g., to get a callback that takes kwargs you have to define a protocol with a `__call__` method that takes kwargs because you can't express it with `typing.Callable`. Similarly where a language with first-class support for types might have `type Foo<T>`, Python makes you write `T = TypeVar("T"); class Foo(Generic[T])` or something like that, and it gets more confusing when you only want one of the methods to be generic and I can never remember whether that `T` takes on a single type across all uses or which scope I need to define it in, etc. This is largely an ergonomic nightmare and I don't have lots of optimism for this stuff to improve unless the Python community really comes to embrace typing as the default way to use Python (but I suspect most people who care a lot about this kind of stuff will leave for Go or other languages where these things just work out of the box).

I have yet to successfully build a project with the strict mypy settings, without resorting to either turning some off or having to use an explicit Any. And a lot of the non-default settings are absolutely critical if you care about correctness.

Lack of recursive types has been a major deal breaker for me. If you have a class Foo that can construct a class Bar, and a class Bar that can construct a class Foo, you can't express that in mypy without Any-Generics.

To me, at this point, mypy is barely a linter, it's more of a "this helps my IDE autocomplete faster", and definitely not a type system.

I also struggle with Mypy's strict mode, but I think recursive types are different from classes that can construct each other. Mypy doesn't have any problem with the following code

    from __future__ import annotations


    class X:
        def __init__(self, value: int) -> None:
            self.value = value

        def to_y(self) -> Y:
            return Y(self.value)


    class Y:
        def __init__(self, value: int) -> None:
            self.value = value

        def to_x(self) -> X:
            return X(self.value)


    x = X(10).to_y().to_x()
    print(x.value)

Sorry, yes, that works. I should have been a little more explicit. This breaks down when Y is generic over X and X is generic over Y. IDK, I've had tons of problems with mutually recursive TypeVars, though my example was not of that - sorry.

This pretty much mirrors my mypy experience too. The only project I've ever successfully used it on was a single-file CLI tool that only used the stdlib.

And by "successfully" I mean "it ran at all". Every other thing I've thrown at it has caused it to crash. I quite like the concept, but implementation has been rather abysmal as far as I've seen. Has it improved in ~ the past year?

I've been using it recently, but just as a vscode plug in for type hints, I don't run any additional checks afterwards, but it seems to catch type errors before execution. But it's been cpu intensive in a wsl container on larger >2k line py files. I haven't tried many others tho, so not really sure if there are better options out there.

Not really, no.

> Similarly where a language with first-class support for types might have `type Foo<T>`, Python makes you write `T = TypeVar("T"); class Foo(Generic[T])` or something like that, and it gets more confusing when you only want one of the methods to be generic and I can never remember whether that `T` takes on a single type across all uses or which scope I need to define it in, etc.

I don't know about you but I find PEP 484 very clear here: https://www.python.org/dev/peps/pep-0484/#scoping-rules-for-...

The PEP is clear, it's just extremely unintuitive that, within the scope of declaration, a type T can be many different types.

Fair enough. Maybe I didn't come across that at the time or perhaps it's been since revised. Even still, it's a poor substitution for the more familiar / intuitive `class Foo[T]:` / `def foo[T](...)` style.

Hmm it might take some getting used to but I've actually found it quite straight-forward to comprehend and reason about.

The nice thing is that, since TypeVars are ordinary variables, you can re-use them / import them in multiple modules and avoid a lot of boilerplate code.

> The nice thing is that, since TypeVars are ordinary variables, you can re-use them / import them in multiple modules and avoid a lot of boilerplate code.

Maybe I'm missing something, but the boilerplate only exists because Python makes you define them as ordinary variables in the first place. So while you can have a `foo.py` file like this:

    T = TypeVar("T")

And a `bar.py` file like this:

    from foo import T

    class Bar(Generic[T]):
        ...

So are you saying that this is less boilerplate than a `bar.py` that just defines its own `T` TypeVar? Because that seems like a pretty comparable amount of boilerplate. Or are you saying that it's less boilerplate than languages that don't treat TypeVars as ordinary variables, e.g., Rust? Because in Rust our `bar.rs` file would look like this: `struct Bar<T> {...}` (and the scoping rules are patently obvious, to boot).

No, in this particular example, there's no real advantage. What I meant were situations where the TypeVar gets a little more complicated, compare the additional parameters on https://docs.python.org/3/library/typing.html#typing.TypeVar . Then importing TypeVars starts to pay off because you only have to define your bounds etc. once.

Ah, that makes sense. Thanks for clarifying.

This is all true. So true infact that I wrote a huge article documenting this for people who are new to it: https://tshr.me/mypy

I'm planning to migrate this to my own blog soon.

> The problems for which I'm less optimistic tend to revolve around shoehorning typing into existing Python syntax--e.g., to get a callback that takes kwargs you have to define a protocol with a `__call__` method that takes kwargs because you can't express it with `typing.Callable`

You might be interested in the discussion over here then -> https://github.com/python/typing/issues/769#issuecomment-741...

Seconding this setup for both VSCode and emacs

Reply on news.ycombinator.com