4 ms·

Great, but how does it compare to Pyright on the utility / performance curve? Pyright is mature and already very fast. https://github.com/microsoft/pyright htt

by mil22 1y ago

Great, but how does it compare to Pyright on the utility / performance curve? Pyright is mature and already very fast. https://github.com/microsoft/pyright https://github.com/microsoft/pyright

nine_k 1y ago
Pyright is good, but it's quite a memory hog. (Yes, I have plenty of RAM on my machine. No, it has other uses during development, too.)
bjourne 1y ago
Pyright is only for type-checking and it lacks many features you'd expected from a modern LSP (I forgot which). Hence, it was forked and someone created basedpyright to fix it: https://github.com/DetachHead/basedpyright https://github.com/DetachHead/basedpyright
- dathinab 1y ago
  To extend on this: In python it's pretty common to have LSP separate from type checking separate from linting (e.g. ruff+mypy+ide_specific_lsp). Which to be fair sucks (as it limits what the LSP can do, can lead to confusing mismatches in error/no-error and on one recent project I had issues with the default LSP run by vscode starting to fall apart and failing to propose auto imports for some trivial things for part of the project....) But it's the stack where pyright fits in.
  - geekraver 1y ago
    The pylance team has started exploring this, namely whether it makes sense to have an API for type checkers that is not the LSP, as language servers have a somewhat different goal in which type checking/inference is an enabling technology. This could allow multiple different language servers to be built on top of different type checkers (and the type checkers can run out-of-proc, so implementation languages can be different). https://github.com/microsoft/pylance-release/discussions/7180 https://github.com/microsoft/pylance-release/discussions/718...
catlover76 1y ago
[dead]
insane_dreamer 1y ago
in my experience pyright is unable to infer many inherited object types (compared to PyCharm's type inference)
- lemontheme 1y ago
  PyCharm definitely excels on more ‘dynamic’ code but the number of times I’ve pulled in code written by colleagues using PyCharm only to get a rainbow of type errors from Pyright is too damn high. The PyCharm checker seems to miss really, really obvious things, e.g. allowing a call site to expect a string while the function returns bytes or none. Maybe my colleagues just have it configured wrong but there’s several of them and the config isn’t shared.
0xFF0123 1y ago
Pyright is incredibly slow in my experience, I've seen it take over a minute on complex codebases
mil22 1y ago
I tested it side-by-side on my ~100Kloc codebase. Ty: 2.5 seconds, 1599 diagnostics, almost all of which are false positives Pyright: 13.6 seconds, 10 errors, all of which are actually real errors There's plenty of potential here, but Ty's type inference is just not as sophisticated as Pyright's at this time. That's not surprising given it hasn't even been released yet. Whether Ty will still perform so much faster once all of Pyright's type inference abilities have been matched or implemented - well, that remains to be seen. Pyright runs on Node, so I would expect it to be a little slower than Ty, but perhaps not by very much, since modern JS engines are already quite fast and perform within a factor of ~2-3x of Rust. That said, I'm rooting for Ty here, since even a 2-3x performance boost would be useful.
- the_duke 1y ago
  Compilation / type checking depends on a lot of trees of typed data, and operating on those tree nodes. That's something where a statically typed language with custom data structures that allows for optimised representations makes a big difference, and where a lot of the fancy optimisations in v8 don't work so well. There is a reason Typescript moved to a typed language.
  - mil22 1y ago
    Let's hope you're right and that translates to even higher performance for Ty compared to Pyright. There are of course many variables and gotchas with these sorts of things.
rtpg 1y ago
I don't get why so many people go to bat for pyright, my experience with it has been pretty miserable. Open enough instances of it and you're in OOM city. It works, but often gets confused... and of course the absolute audacity of MSFT to say "let's go over to pyright, and by the way we're going to carve up some stuff and put it into pylance instead", meaning that it's totally not within the actual spirit of open source. I would like to just not use it, but the existence of pyright as a _barely_ functional alternative really sucks the air out of other attempts' continued existence. Real "extend/extinguish" behavior from MSFT.
- lemontheme 1y ago
  If you haven’t checked it out already, basedpyright is pyright with all the arbitrarily carved out functionality put back in – plus some extra features that you may or may not find useful depending on how strict you like your typing. Can’t recommend it enough
  - rtpg 1y ago
    To be honest I can't respect a project that names itself like that. I am a working professional.
- mil22 1y ago
  I tried all the type checkers available as of ~1 year ago, and Pyright worked the best for me. It's not perfect, but it's better than any of the pure Python checkers. Memory is cheap (unless you're buying it from Apple I guess...). Would I take a faster type checker with better memory footprint? Heck yes, assuming equal or superior functionality.
  - rtpg 1y ago
    Memory ain’t that cheap on laptops in general! The bigger issue is less “pyright” and more “every tool out there being as heavy as pyright” + docker etc… but things are getting better IMO

by mil22 1y ago

Great, but how does it compare to Pyright on the utility / performance curve? Pyright is mature and already very fast. https://github.com/microsoft/pyright https://github.com/microsoft/pyright

nine_k 1y ago

Pyright is good, but it's quite a memory hog. (Yes, I have plenty of RAM on my machine. No, it has other uses during development, too.)

bjourne 1y ago

Pyright is only for type-checking and it lacks many features you'd expected from a modern LSP (I forgot which). Hence, it was forked and someone created basedpyright to fix it: https://github.com/DetachHead/basedpyright https://github.com/DetachHead/basedpyright

dathinab 1y ago
To extend on this: In python it's pretty common to have LSP separate from type checking separate from linting (e.g. ruff+mypy+ide_specific_lsp). Which to be fair sucks (as it limits what the LSP can do, can lead to confusing mismatches in error/no-error and on one recent project I had issues with the default LSP run by vscode starting to fall apart and failing to propose auto imports for some trivial things for part of the project....) But it's the stack where pyright fits in.
- geekraver 1y ago
  The pylance team has started exploring this, namely whether it makes sense to have an API for type checkers that is not the LSP, as language servers have a somewhat different goal in which type checking/inference is an enabling technology. This could allow multiple different language servers to be built on top of different type checkers (and the type checkers can run out-of-proc, so implementation languages can be different). https://github.com/microsoft/pylance-release/discussions/7180 https://github.com/microsoft/pylance-release/discussions/718...

catlover76 1y ago

[dead]

insane_dreamer 1y ago

in my experience pyright is unable to infer many inherited object types (compared to PyCharm's type inference)

lemontheme 1y ago
PyCharm definitely excels on more ‘dynamic’ code but the number of times I’ve pulled in code written by colleagues using PyCharm only to get a rainbow of type errors from Pyright is too damn high. The PyCharm checker seems to miss really, really obvious things, e.g. allowing a call site to expect a string while the function returns bytes or none. Maybe my colleagues just have it configured wrong but there’s several of them and the config isn’t shared.

0xFF0123 1y ago

Pyright is incredibly slow in my experience, I've seen it take over a minute on complex codebases

mil22 1y ago

I tested it side-by-side on my ~100Kloc codebase. Ty: 2.5 seconds, 1599 diagnostics, almost all of which are false positives Pyright: 13.6 seconds, 10 errors, all of which are actually real errors There's plenty of potential here, but Ty's type inference is just not as sophisticated as Pyright's at this time. That's not surprising given it hasn't even been released yet. Whether Ty will still perform so much faster once all of Pyright's type inference abilities have been matched or implemented - well, that remains to be seen. Pyright runs on Node, so I would expect it to be a little slower than Ty, but perhaps not by very much, since modern JS engines are already quite fast and perform within a factor of ~2-3x of Rust. That said, I'm rooting for Ty here, since even a 2-3x performance boost would be useful.

the_duke 1y ago
Compilation / type checking depends on a lot of trees of typed data, and operating on those tree nodes. That's something where a statically typed language with custom data structures that allows for optimised representations makes a big difference, and where a lot of the fancy optimisations in v8 don't work so well. There is a reason Typescript moved to a typed language.
- mil22 1y ago
  Let's hope you're right and that translates to even higher performance for Ty compared to Pyright. There are of course many variables and gotchas with these sorts of things.

rtpg 1y ago

I don't get why so many people go to bat for pyright, my experience with it has been pretty miserable. Open enough instances of it and you're in OOM city. It works, but often gets confused... and of course the absolute audacity of MSFT to say "let's go over to pyright, and by the way we're going to carve up some stuff and put it into pylance instead", meaning that it's totally not within the actual spirit of open source. I would like to just not use it, but the existence of pyright as a _barely_ functional alternative really sucks the air out of other attempts' continued existence. Real "extend/extinguish" behavior from MSFT.

lemontheme 1y ago
If you haven’t checked it out already, basedpyright is pyright with all the arbitrarily carved out functionality put back in – plus some extra features that you may or may not find useful depending on how strict you like your typing. Can’t recommend it enough
- rtpg 1y ago
  To be honest I can't respect a project that names itself like that. I am a working professional.
mil22 1y ago
I tried all the type checkers available as of ~1 year ago, and Pyright worked the best for me. It's not perfect, but it's better than any of the pure Python checkers. Memory is cheap (unless you're buying it from Apple I guess...). Would I take a faster type checker with better memory footprint? Heck yes, assuming equal or superior functionality.
- rtpg 1y ago
  Memory ain’t that cheap on laptops in general! The bigger issue is less “pyright” and more “every tool out there being as heavy as pyright” + docker etc… but things are getting better IMO