Hacker News Reader

Comment by samwillis | Hacker News Reader

From this comparison (https://github.com/microsoft/pyright/blob/main/docs/mypy-com...) it looks like Pyright fixes a load of issues that MyPy has. It also seems much closer to how TypeScript works (I have worked significantly more with TypeScript than typed Python and really like it)

Is there a reason not to go with Pyright and stick with MyPy?

View on HN

Typescript similarity is expected as maintainer of pyright does talk with typescript maintainers and sometimes pyright adds features inspired by typescript's inference.

I think the major reasons for mypy is if you are working on a library to be shared with many others (especially open source one) you'd like library to be compatible with mypy as your users are likely to use mypy as it's still most popular type checker. So for open source libraries it makes sense to use both mypy/pyright. For projects that you do not expect main users (company internal one you define standards) it's more fine to pick type checker you prefer. The other main place mypy can be helpful is plugins if you need some behavior outside of type system for a library you work with a lot.

Also pyright is implemented in typescript which does mean you'll need to have a CI dependency on javascript environment that python project's often don't need. Lastly for typical python developer it's a bit easier to make pull request to mypy vs pyright just as they normally have more python knowledge then javascript knowledge. This is pretty minor given most people don't debug there own type checker and pyright's bug list is very short.

Mypy supports plugins. That's the only advantage I'm aware of. I like Pyright because it has a track record of adding new type features months ahead of Mypy (e.g. recursive types, ParamSpec).

Pyright doesn't support narrowing based on object truthiness and some other python isms.

In my experience, mypy tends to be more correct and correctly understands more python code.

For example, the following won't type check in pyright (it doesn't infer the type of out):

    out = []
    for x in bar:
      out.append(x \* 2)
    return out

Edit: also pyright's vendoring of type stubs is annoying as they take precedence over downloaded type stubs.

Edit2: also lack of plugins, makes using things like Pydantic less type safe compared to mypy

Pyright's vendoring of stubs or pylance's? Pylance vendors extra stubs (microsoft type stubs), but pyright itself does not. Pyright does vendor typeshed, but all type checkers including mypy vendor typeshed.

Narrowing on object truthiness unsure what you mean. That's intended to be supported. The out example is real difference where mypy does do better. It should at least type check on basic pyright but won't type check on strict without doing out: list[int]. That one comes from mypy has special handling for lists to allow inferring type of elements later, while pyright always infers type of a variable only based on it's declarations and never it's method calls like append.

If you have a tagged union type with Boolean literals as the tags, like in the slack api, then you can’t say ‘if not res.ok’ to narrow the type, you have to say ‘if res.ok == True’

Which isn’t very pythonic imho

Also I’m pretty sure ‘if res.ok is True’ doesn’t work

The precedence should be: "typing" folder in workspace root -> project "extra paths" -> python search paths -> pylance bundled.

If that's not working for you you should open an issue at https://github.com/microsoft/pylance-release.

Reply on news.ycombinator.com