8 ms·

Pyright: Static Type Checker for Python

152 points by pen2l 4y ago

threadweaver34 4y ago
I can't decide if it's a feature or a bug that there are at least 3 major type checkers for Python.
- nine_k 4y ago
  It's a consequence of Python never having been designed as a language with a static type system. In fact, Python is utterly dynamic and has a number of mechanisms that allow to write code which defies and mocks any attempts at static typing. When the pain of maintaining larger codebases resulted in attempts to add static type checking (ultimately successful), it was, and still is, impossible to produce a solution that would work equally well for all kinds of codebases. Stricter tools show too many "false positives", laxer tools miss too many cases that a real static type checker would flag. Say, things that Django does (not to mention Zope) can only be described well by special-casing them. Hence different tools which strike different kinds of compromises.
  - amarshall 4y ago
    > It's a consequence of Python never having been designed as a language with a static type system Is it? Mypy is semi-official and has Guido as a contributor. It also predates both pyright and pyre by many years. Honestly I find it somewhat sad that huge tech companies create their own instead of contributing to an existing and popular implementation. But perhaps the internal versions predated Mypy by a lot.
    - Mehdi2277 4y ago
      Pyright is pretty recent and started development years after mypy. But some of pyright's design goals (laziness for LSP) would have made it very difficult to do in mypy without a very large refactor/rewrite. Pyright is implemented in typescript for better LSP/vscode integration and performance. pytype (google's type checker) is only one I know that predates mypy for when it started development. Pyre's reason is interesting, https://github.com/facebook/pyre-check/issues/38 https://github.com/facebook/pyre-check/issues/38. Pyre is based off of Hack, facebook's php compiler. Facebook made pyre to re-use tooling/techniques from Hack on python. Secondary reason is performance. Pyre is done in OCaml and having same performance in type checker implemented within python is hard.
eatonphil 4y ago
To the obvious question: how does this differ from mypy? tldr; mostly about performance improvements but there's also semantic differences. The latter sounds like it means a split between the community who decides to do mypy vs pyright. But maybe pyright only differs with mypy in terms of things that are considered bugs in mypy, and things that are optional in mypy (via flags). https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com....
- Mehdi2277 4y ago
  I’ve heavily used both mypy/pyright. The semantic differences are mainly in areas where type system is not specific enough on exact behavior expected. As an example if you have a function that has overloads how do you decide which overload to pick? Sometimes that can become ambiguous especially when type variables are involved or multiple overloads match. Cases like that are where you see most intentional differences and as a user of both type checkers I consider depending on specific behavior there to be like using c++ compiler’s undefined behavior. The bigger area I see differences is feature development/bug fix velocity. Mypy is maintained well. Pyright is maintained magically and I’ve reported bugs that maintainer fixes the same day. Most bug reports to pyright get fixed in a week. Only a couple tend to stay open for a while. New type system features (peps) get implemented really fast in pyright and usually if you try to use very recent features you will need to wait a while for mypy to catch up. A good example is release time for paramspecs or typevartuple. Most of the time new type system peps are added in pyright while still in draft stage.
  - Recursing 4y ago
    An important difference is that pyright doesn't support plug-ins. https://github.com/microsoft/pyright/issues/607 https://github.com/microsoft/pyright/issues/607 E.g. https://github.com/Shoobx/mypy-zope https://github.com/Shoobx/mypy-zope can't work with pyright
    - samwillis 4y ago
      After quickly skimming that issue thread I think the Pyright devs have a very compelling argument not to add a plug-in system. It would encourage none standard behaviour, when really the type system should be capable of describing all behaviour. I think it may be another plus for it.
deleted 4y ago
[deleted]
wcdolphin 4y ago
Has anyone migrated a large code base between MyPy and Pyright? In particular would love to hear about experiences with Django. Mypy’s performance and the join based type merging are quite limiting. At the same time, the ecosystem support around MyPy seems strong.
- Mehdi2277 4y ago
  Django is one library that has some apis that are beyond type system and likely difficult to ever fully describe in type system. Some of this it handles with a custom mypy plugin to overrule/extend some type rules. No other python type checker I'm aware of supports plugins so this is one place mypy will have an advantage. Usually when behavior is too dynamic to be described well the stubs will fallback to Any leaving some typing holes for other type checkers. At same time this only affects a subset of Django behavior and I have used pyright with a Django codebase and it mostly worked well. The more you use very dynamic features of Django the more this matters. One note for both is you do want to tune configuration settings. Pyright basic is fairly easy to satisfy, pyright strict is too hard for most codebases. Similarly mypy defaults are too lenient, but mypy strict is pretty hard (even mypy doesn't use strict to check itself). I roughly go for strict for both and then remove ~5 hardest rules and call that good enough. Strictest rules pretty much require all of your dependencies to be well typed/stubbed.
- davepeck 4y ago
  Yes. I moved a very large/mature Django project from use of MyPy to use of Pyright. My experience was that pyright flagged a bunch of new conditions that MyPy seemed to have missed. The cost was that I needed to add (many!) explicit annotations or casts in places the Django MyPy plug-in would have just “known” about the types, for instance in foreign key relations in Models. In general, we were very happy with the result and never looked back. Correctness and perf were both notably improved. (That pyright is also part of pylance, Microsoft’s proprietary LSP implementation for Python that plays well with VSCode, was an advantage for this particular team.) This was about a year and a half ago so the experience may differ; both pyright and mypy + its plugins have gotten more capable and mature over time.
samwillis 4y ago
From this comparison (https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md 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?
- Mehdi2277 4y ago
  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.
- wendyshu 4y ago
  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).
- emptysea 4y ago
  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
deleted 4y ago
[deleted]
dang 4y ago
Related: Pyright: Static type checker for Python - https://news.ycombinator.com/item?id=19473631 https://news.ycombinator.com/item?id=19473631 - March 2019 (87 comments) Also: Using Mypy in Production - https://news.ycombinator.com/item?id=32556816 https://news.ycombinator.com/item?id=32556816 - Aug 2022 (129 comments) Exhaustiveness Checking with Mypy - https://news.ycombinator.com/item?id=25428583 https://news.ycombinator.com/item?id=25428583 - Dec 2020 (19 comments) Applying Mypy to real-world projects - https://news.ycombinator.com/item?id=22302789 https://news.ycombinator.com/item?id=22302789 - Feb 2020 (23 comments) Statically-typed error handling in Python using Mypy - https://news.ycombinator.com/item?id=21736620 https://news.ycombinator.com/item?id=21736620 - Dec 2019 (126 comments) Pytype – A static type analyzer for Python code - https://news.ycombinator.com/item?id=19476605 https://news.ycombinator.com/item?id=19476605 - March 2019 (29 comments) Pyre: Facebook's static type checker for Python - https://news.ycombinator.com/item?id=19476286 https://news.ycombinator.com/item?id=19476286 - March 2019 (2 comments) Type hints cheat sheet (Python 3) - https://news.ycombinator.com/item?id=18660309 https://news.ycombinator.com/item?id=18660309 - Dec 2018 (18 comments) PyAnnotate – Auto-generate type annotations for mypy - https://news.ycombinator.com/item?id=15707877 https://news.ycombinator.com/item?id=15707877 - Nov 2017 (33 comments) Static types in Python - https://news.ycombinator.com/item?id=12703008 https://news.ycombinator.com/item?id=12703008 - Oct 2016 (221 comments) Typed Python: new Mypy release - https://news.ycombinator.com/item?id=11641245 https://news.ycombinator.com/item?id=11641245 - May 2016 (46 comments) Mypy 0.3 Released – optional static type checker for Python - https://news.ycombinator.com/item?id=11134647 https://news.ycombinator.com/item?id=11134647 - Feb 2016 (19 comments) Mypy – static type checking for Python 3 - https://news.ycombinator.com/item?id=8191916 https://news.ycombinator.com/item?id=8191916 - Aug 2014 (29 comments) Mypy - An experimental Python variant with dynamic and static typing - https://news.ycombinator.com/item?id=4561973 https://news.ycombinator.com/item?id=4561973 - Sept 2012 (39 comments)
toinbis 4y ago
I use both mypy and pyright. Pre-commit hook/vscode runs checks for mypy, pyright, as well as pylint, flake8, black, bandit. Why both? I just have more confidence in getting feedback from both of the tools.
gjvc 4y ago
better (more suggestive) name than "mypy"
pedrovhb 4y ago
I've been using pyright more than mypy these days; playing with higher order functions I have pulled about half of my hair out because of things that more often than not turn out to be mypy bugs. I've tried pyre, and that's better too, in my experience. The codebases of mypy and pyre are starkly different in terms of organization (though pyre does the heavy lifting in OCaml). Haven't looked at pyright's yet. Besides the bug count, it's kind of weird to see the "reference" type checker for Python constantly lagging behind in terms of features, experimental ones but also ones that have already been accepted PEPs for a while. Meanwhile pyre and pyright both have usually had features for _months_ before mypy has even started implementing them. As a side question, does anyone know how I can easily interface with an LSP client from Python? I'm itching to build something that gives me some custom typing insight as I write code, and it's probably more robust to consult LSP than to parse CLI output.
- jsmeaton 4y ago
  I don’t know if this helps with your actual problem but if you use vscode you can enable inline typehints and all variables will show their inferred types right in the editor. I personally find it too noisy but it sounds almost like what you want to build so thought I’d mention it.
29athrowaway 4y ago
Microsoft: "Where do you want to go today?" https://youtu.be/T4oNA8ViuwI?t=63 https://youtu.be/T4oNA8ViuwI?t=63
nezirus 4y ago
I can vouch for use of Pyright as LSP for neovim and helix. Very useful, especially the strict mode. I usually pair it with pyre, another great tool https://github.com/facebook/pyre-check https://github.com/facebook/pyre-check
- tomtom1337 4y ago
  Could you comment on why you use both pyright and pure?
  - nezirus 4y ago
    Better late than never :) FB people have great experience with introducing typing into weakly typed languages (e.g. PHP vs Hack). So I actually started using pyre-check in place of mypy. The tool is really great and fast. I also like pysa quite a lot. Pyright only came into focus because it was best Python LSP implementation for NeoVim, and it is also the default for helix-editor which I play with. It's also nice that I could suggest pyright for some younger colleagues using VisualStudio Code (with strict mode enabled of course). P.S. I'm also using other interesting tools and libraries from FB (Instagram) like libcst [1] or fixit [2] [1] https://github.com/Instagram/LibCST/ https://github.com/Instagram/LibCST/ [2] https://github.com/Instagram/Fixit https://github.com/Instagram/Fixit
tlarkworthy 4y ago
It's written in Typescript I would love to type check python in the browser without running pyodine, does anyone know how?
- tyingq 4y ago
  This issue has some pointers: https://github.com/microsoft/pyright/discussions/3222 https://github.com/microsoft/pyright/discussions/3222
  - tlarkworthy 4y ago
    Wow that's pure gold
- jaustin 4y ago
  The Micro:bit Educational Foundation do it for https://python.microbit.org/ https://python.microbit.org/ where the scope is conveniently limited (to MicroPython running on a device with finite flash/RAM) https://github.com/microbit-foundation/pyright https://github.com/microbit-foundation/pyright (and more specifically https://github.com/microbit-foundation/pyright/blob/microbit/THIS_FORK.md https://github.com/microbit-foundation/pyright/blob/microbit... )
  - tlarkworthy 4y ago
    Oh wow, their pyright-browswr package is very nice, the writeup works well!
chaychoong 4y ago
For Neovim users that use LSP + completion + snippets, it is slightly unfortunate that the Pyright team does not plan to support snippets on Pyright (but open to supporting it on Pylance, which is not OSS). https://github.com/microsoft/pyright/issues/924 https://github.com/microsoft/pyright/issues/924
kelsolaar 4y ago
Moved Colour to Pyright a few weeks ago, our Mypy checks on Github Actions were taking 1h30. Those speed regressions were fixed recently though but Pyright is still much faster and seems stricter, finding more legit issues than Mypy.

152 points by pen2l 4y ago

threadweaver34 4y ago

I can't decide if it's a feature or a bug that there are at least 3 major type checkers for Python.

nine_k 4y ago
It's a consequence of Python never having been designed as a language with a static type system. In fact, Python is utterly dynamic and has a number of mechanisms that allow to write code which defies and mocks any attempts at static typing. When the pain of maintaining larger codebases resulted in attempts to add static type checking (ultimately successful), it was, and still is, impossible to produce a solution that would work equally well for all kinds of codebases. Stricter tools show too many "false positives", laxer tools miss too many cases that a real static type checker would flag. Say, things that Django does (not to mention Zope) can only be described well by special-casing them. Hence different tools which strike different kinds of compromises.
- amarshall 4y ago
  > It's a consequence of Python never having been designed as a language with a static type system Is it? Mypy is semi-official and has Guido as a contributor. It also predates both pyright and pyre by many years. Honestly I find it somewhat sad that huge tech companies create their own instead of contributing to an existing and popular implementation. But perhaps the internal versions predated Mypy by a lot.
  - Mehdi2277 4y ago
    Pyright is pretty recent and started development years after mypy. But some of pyright's design goals (laziness for LSP) would have made it very difficult to do in mypy without a very large refactor/rewrite. Pyright is implemented in typescript for better LSP/vscode integration and performance. pytype (google's type checker) is only one I know that predates mypy for when it started development. Pyre's reason is interesting, https://github.com/facebook/pyre-check/issues/38 https://github.com/facebook/pyre-check/issues/38. Pyre is based off of Hack, facebook's php compiler. Facebook made pyre to re-use tooling/techniques from Hack on python. Secondary reason is performance. Pyre is done in OCaml and having same performance in type checker implemented within python is hard.

eatonphil 4y ago

To the obvious question: how does this differ from mypy? tldr; mostly about performance improvements but there's also semantic differences. The latter sounds like it means a split between the community who decides to do mypy vs pyright. But maybe pyright only differs with mypy in terms of things that are considered bugs in mypy, and things that are optional in mypy (via flags). https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com....

Mehdi2277 4y ago
I’ve heavily used both mypy/pyright. The semantic differences are mainly in areas where type system is not specific enough on exact behavior expected. As an example if you have a function that has overloads how do you decide which overload to pick? Sometimes that can become ambiguous especially when type variables are involved or multiple overloads match. Cases like that are where you see most intentional differences and as a user of both type checkers I consider depending on specific behavior there to be like using c++ compiler’s undefined behavior. The bigger area I see differences is feature development/bug fix velocity. Mypy is maintained well. Pyright is maintained magically and I’ve reported bugs that maintainer fixes the same day. Most bug reports to pyright get fixed in a week. Only a couple tend to stay open for a while. New type system features (peps) get implemented really fast in pyright and usually if you try to use very recent features you will need to wait a while for mypy to catch up. A good example is release time for paramspecs or typevartuple. Most of the time new type system peps are added in pyright while still in draft stage.
- Recursing 4y ago
  An important difference is that pyright doesn't support plug-ins. https://github.com/microsoft/pyright/issues/607 https://github.com/microsoft/pyright/issues/607 E.g. https://github.com/Shoobx/mypy-zope https://github.com/Shoobx/mypy-zope can't work with pyright
  - samwillis 4y ago
    After quickly skimming that issue thread I think the Pyright devs have a very compelling argument not to add a plug-in system. It would encourage none standard behaviour, when really the type system should be capable of describing all behaviour. I think it may be another plus for it.

deleted 4y ago

[deleted]

wcdolphin 4y ago

Has anyone migrated a large code base between MyPy and Pyright? In particular would love to hear about experiences with Django. Mypy’s performance and the join based type merging are quite limiting. At the same time, the ecosystem support around MyPy seems strong.

Mehdi2277 4y ago
Django is one library that has some apis that are beyond type system and likely difficult to ever fully describe in type system. Some of this it handles with a custom mypy plugin to overrule/extend some type rules. No other python type checker I'm aware of supports plugins so this is one place mypy will have an advantage. Usually when behavior is too dynamic to be described well the stubs will fallback to Any leaving some typing holes for other type checkers. At same time this only affects a subset of Django behavior and I have used pyright with a Django codebase and it mostly worked well. The more you use very dynamic features of Django the more this matters. One note for both is you do want to tune configuration settings. Pyright basic is fairly easy to satisfy, pyright strict is too hard for most codebases. Similarly mypy defaults are too lenient, but mypy strict is pretty hard (even mypy doesn't use strict to check itself). I roughly go for strict for both and then remove ~5 hardest rules and call that good enough. Strictest rules pretty much require all of your dependencies to be well typed/stubbed.
davepeck 4y ago
Yes. I moved a very large/mature Django project from use of MyPy to use of Pyright. My experience was that pyright flagged a bunch of new conditions that MyPy seemed to have missed. The cost was that I needed to add (many!) explicit annotations or casts in places the Django MyPy plug-in would have just “known” about the types, for instance in foreign key relations in Models. In general, we were very happy with the result and never looked back. Correctness and perf were both notably improved. (That pyright is also part of pylance, Microsoft’s proprietary LSP implementation for Python that plays well with VSCode, was an advantage for this particular team.) This was about a year and a half ago so the experience may differ; both pyright and mypy + its plugins have gotten more capable and mature over time.

samwillis 4y ago

From this comparison (https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md 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?

Mehdi2277 4y ago
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.
wendyshu 4y ago
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).
emptysea 4y ago
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

deleted 4y ago

[deleted]

dang 4y ago

Related: Pyright: Static type checker for Python - https://news.ycombinator.com/item?id=19473631 https://news.ycombinator.com/item?id=19473631 - March 2019 (87 comments) Also: Using Mypy in Production - https://news.ycombinator.com/item?id=32556816 https://news.ycombinator.com/item?id=32556816 - Aug 2022 (129 comments) Exhaustiveness Checking with Mypy - https://news.ycombinator.com/item?id=25428583 https://news.ycombinator.com/item?id=25428583 - Dec 2020 (19 comments) Applying Mypy to real-world projects - https://news.ycombinator.com/item?id=22302789 https://news.ycombinator.com/item?id=22302789 - Feb 2020 (23 comments) Statically-typed error handling in Python using Mypy - https://news.ycombinator.com/item?id=21736620 https://news.ycombinator.com/item?id=21736620 - Dec 2019 (126 comments) Pytype – A static type analyzer for Python code - https://news.ycombinator.com/item?id=19476605 https://news.ycombinator.com/item?id=19476605 - March 2019 (29 comments) Pyre: Facebook's static type checker for Python - https://news.ycombinator.com/item?id=19476286 https://news.ycombinator.com/item?id=19476286 - March 2019 (2 comments) Type hints cheat sheet (Python 3) - https://news.ycombinator.com/item?id=18660309 https://news.ycombinator.com/item?id=18660309 - Dec 2018 (18 comments) PyAnnotate – Auto-generate type annotations for mypy - https://news.ycombinator.com/item?id=15707877 https://news.ycombinator.com/item?id=15707877 - Nov 2017 (33 comments) Static types in Python - https://news.ycombinator.com/item?id=12703008 https://news.ycombinator.com/item?id=12703008 - Oct 2016 (221 comments) Typed Python: new Mypy release - https://news.ycombinator.com/item?id=11641245 https://news.ycombinator.com/item?id=11641245 - May 2016 (46 comments) Mypy 0.3 Released – optional static type checker for Python - https://news.ycombinator.com/item?id=11134647 https://news.ycombinator.com/item?id=11134647 - Feb 2016 (19 comments) Mypy – static type checking for Python 3 - https://news.ycombinator.com/item?id=8191916 https://news.ycombinator.com/item?id=8191916 - Aug 2014 (29 comments) Mypy - An experimental Python variant with dynamic and static typing - https://news.ycombinator.com/item?id=4561973 https://news.ycombinator.com/item?id=4561973 - Sept 2012 (39 comments)

toinbis 4y ago

I use both mypy and pyright. Pre-commit hook/vscode runs checks for mypy, pyright, as well as pylint, flake8, black, bandit. Why both? I just have more confidence in getting feedback from both of the tools.

gjvc 4y ago

better (more suggestive) name than "mypy"

pedrovhb 4y ago

I've been using pyright more than mypy these days; playing with higher order functions I have pulled about half of my hair out because of things that more often than not turn out to be mypy bugs. I've tried pyre, and that's better too, in my experience. The codebases of mypy and pyre are starkly different in terms of organization (though pyre does the heavy lifting in OCaml). Haven't looked at pyright's yet. Besides the bug count, it's kind of weird to see the "reference" type checker for Python constantly lagging behind in terms of features, experimental ones but also ones that have already been accepted PEPs for a while. Meanwhile pyre and pyright both have usually had features for _months_ before mypy has even started implementing them. As a side question, does anyone know how I can easily interface with an LSP client from Python? I'm itching to build something that gives me some custom typing insight as I write code, and it's probably more robust to consult LSP than to parse CLI output.

jsmeaton 4y ago
I don’t know if this helps with your actual problem but if you use vscode you can enable inline typehints and all variables will show their inferred types right in the editor. I personally find it too noisy but it sounds almost like what you want to build so thought I’d mention it.

29athrowaway 4y ago

Microsoft: "Where do you want to go today?" https://youtu.be/T4oNA8ViuwI?t=63 https://youtu.be/T4oNA8ViuwI?t=63

nezirus 4y ago

I can vouch for use of Pyright as LSP for neovim and helix. Very useful, especially the strict mode. I usually pair it with pyre, another great tool https://github.com/facebook/pyre-check https://github.com/facebook/pyre-check

tomtom1337 4y ago
Could you comment on why you use both pyright and pure?
- nezirus 4y ago
  Better late than never :) FB people have great experience with introducing typing into weakly typed languages (e.g. PHP vs Hack). So I actually started using pyre-check in place of mypy. The tool is really great and fast. I also like pysa quite a lot. Pyright only came into focus because it was best Python LSP implementation for NeoVim, and it is also the default for helix-editor which I play with. It's also nice that I could suggest pyright for some younger colleagues using VisualStudio Code (with strict mode enabled of course). P.S. I'm also using other interesting tools and libraries from FB (Instagram) like libcst [1] or fixit [2] [1] https://github.com/Instagram/LibCST/ https://github.com/Instagram/LibCST/ [2] https://github.com/Instagram/Fixit https://github.com/Instagram/Fixit

tlarkworthy 4y ago

It's written in Typescript I would love to type check python in the browser without running pyodine, does anyone know how?

tyingq 4y ago
This issue has some pointers: https://github.com/microsoft/pyright/discussions/3222 https://github.com/microsoft/pyright/discussions/3222
- tlarkworthy 4y ago
  Wow that's pure gold
jaustin 4y ago
The Micro:bit Educational Foundation do it for https://python.microbit.org/ https://python.microbit.org/ where the scope is conveniently limited (to MicroPython running on a device with finite flash/RAM) https://github.com/microbit-foundation/pyright https://github.com/microbit-foundation/pyright (and more specifically https://github.com/microbit-foundation/pyright/blob/microbit/THIS_FORK.md https://github.com/microbit-foundation/pyright/blob/microbit... )
- tlarkworthy 4y ago
  Oh wow, their pyright-browswr package is very nice, the writeup works well!

chaychoong 4y ago

For Neovim users that use LSP + completion + snippets, it is slightly unfortunate that the Pyright team does not plan to support snippets on Pyright (but open to supporting it on Pylance, which is not OSS). https://github.com/microsoft/pyright/issues/924 https://github.com/microsoft/pyright/issues/924

kelsolaar 4y ago

Moved Colour to Pyright a few weeks ago, our Mypy checks on Github Actions were taking 1h30. Those speed regressions were fixed recently though but Pyright is still much faster and seems stricter, finding more legit issues than Mypy.