It has warnings that steer you away from idiomatic Python towards less idiomatic Python.

Idiomatic Python favours EAFP (Easier to Ask Forgiveness than Permission) over LBYL (Look Before You Leap), so you might write something like this when using TypedDicts:

    try:
        foo = bar["baz"]["qux"]
        ...
    except KeyError:
        ...

Pyright warns you about this and pushes you to write this:

    if "baz" in bar and "qux" in bar["baz"]:
        foo = bar["baz"]["qux"]
        ...
    else:
        ...

They identified this as a bug and fixed it, then changed course and decided to reinstate the behaviour. So if you want to write idiomatic Python, you need to disable typechecking TypedDicts.

— https://github.com/microsoft/pyright/issues/1739

Now if this were a linter then I would understand. But a type checker should not be opinionated to the point of pushing people not to use idiomatic Python.

For maximum safety, I would write:

    if bar.get("baz", {}).get("qux") is not None:
    ...

any more than 2 levels deep of this pattern and I reach for python-benedict

Nice, I didn't know about that lib! Usually if I have very nested content I recursively parse it and I'll have some business logic in the function to handle cases here and there. Or I'll have a validation library like Pydantic.

When I last compared it to mypy a few months ago adding typechecking to an old project that had types but I had for some reason never actually run a typechecker on it:

* Was overwhelmingly slower than mypy

* Had a few hundred more false positives. I gather from reading their philosophy afterward that this was on purpose. Rigid dogma > doing the right thing in the circumstance in their opinion.

* Did not find any actual bugs, whereas mypy identified 3 errors that lead to fixing real issues AND had fewer false positives, due to its better understanding of python code.

* Comically overweight with its typescript dependency.

My first impression of it was of a very low quality, over engineered project prioritizing noise over signal. Looking forward to trying out the astral typechecker as well.

It's slow as hell. And every version bump comes with a bunch of new warnings/errors by default that is quite disruptive if you want to keep it quiet. But mostly that it is annoyingly slow.

Might be worth checking out https://github.com/DetachHead/basedpyright

But I’ve had the same issue with too many warnings, mypy is better at understanding Python but even slower.

I guess it’s all relative. One of my code bases still has pylint running with only a couple custom lint rules, that one is slow as hell.

As for version bumping, maybe it’s just a me thing, but I hard fix a version and only update occasionally. Sure each update brings new warnings, but most of them are valid and if you only do it a couple times a year… not that big a deal.

Try ruff instead of pylint. It will open your eyes to how performant software can actually be. All of us that have been working in python and JavaScript for too long have really forgotten.

We use ruff for everything that isn’t a custom rule.

The only thing I found it ‘missing’ was an indentation check (it’s in preview, I don’t turn on preview rules), but I realized it doesn’t matter because we also have a formatter running on everything.

It’s dog slow. I realize we are talking about a python checker written in typescript, so two relatively slow languages combined, but still.

The dependency on node makes it a PITA to set up in non-vs code environments as well.

pyright doesn't do well with inspecting inherited types, at least in our experience. Falls far behind JetBrain's type checker in Pycharm. (This is one reason why pycharm >> zed.)

Are you kidding? Pycharm's pychecker is very incomplete. My whole team moved away from pychram due to the shitty typehint support which barely moved forward. (5+ year old bug, inconsistent behavior across the different features in pycharm indicating to me a fragile mess of heuristics behind the curtains)

I agree that most of the functionality on top of the type checker/engine is better in pycharm though. But a correct implementation is more important