4 ms·

I've decided to to try out Pyrefly, Ty and Zuban for their language server features (type checking disabled where possible) last week and found that Zuban is th

by sirfz 1y ago

I've decided to to try out Pyrefly, Ty and Zuban for their language server features (type checking disabled where possible) last week and found that Zuban is the fastest (but unfortunately doesn't currently have the option to disable type checking). Ty comes next and Pyrefly was surprisingly slow to load (have to wait a few seconds before I can goto definition for example). They all lack certain features vs basedpyright (what I was using) such as auto imports (Ty has experimental support), showing signature/doc when selecting autocomplete options (I think Ty does have this one) and some other features that I can't remember. One feature that always existed in Jedi (and now also Zuban) is "goto declaration" in Python. It allowed me to goto the "import" instead of the original definition of a function/class which I'm surprised either isn't supported at all (pyright?) or would just do the same thing as "goto definition" (Ty), seems like an obvious oversight imho. Edit: Also, I wish all these new tools give more importance to such IDE features as much as they do for type checking.

jswny 1y ago
At least for Ty, not sure about the others, it is explicitly for type checking, exposed as an LSP. It’s not trying to compete with full LSP implementations. Most modern editors let you combine multiple LSPs, you shouldn’t think of them as using only one at a time
- ehsanu1 1y ago
  Do you assign different responsibilities to different LSP servers when there multiple I suppose?
- charliermarsh 1y ago
  We actually do want ty to be a first-class LSP (i.e., a complete alternative to Pylance and others), and it already supports nearly all of the features you'd expect. I use it as my primary LSP today in lieu of Pylance!
  - jswny 1y ago
    Good to know, I had no idea!
- sirfz 1y ago
  I understand your confusion because at first look it seems like it's just a type checker (same issue with pyrefly and zuban) hence my comment about bringing forward the fact it's a fully featured lsp
deleted 1y ago
[deleted]
screye 1y ago
If ruff & uv have proved anything, it's that a tool that's effortless, a net-positive and fast will get adopted. New typecheckers don't need to be perfect. They need to be good enough, easy to integrate and have low false positives. Sure, they will improve with time, but if feels like a pain then no one will pick it up. Python users are famously averse to tools that slow down their dev cycles, even if it means better long term stability BasedPyright is popular because it comes built-in with Cursor and disappears into the background. I have a positive bias towards Astral figuring it out given their track record. But, none of these tools have reached the point of effortlessness just yet.
- phplovesong 1y ago
  If typechecking is tongue on cheek, why even bother?
  - atoav 1y ago
    If car crashes still kill people, why wear safety belts?
    - tremon 1y ago
      I don't think that's an accurate metaphor. Seatbelts are expressly a runtime solution to car crashes, whereas Python's type checking is a) only done during development (not even during build), and b) completely reliant on third-party tools. If you're looking for a car analogy, I would suggest comparing Python type checking to installing speed cameras on the factory floor.
      - ObscureScience 1y ago
        The analogy would be mandatory inspections of certain components or manufacturing processes to see that rules and specs are followed while assembling.
    - phplovesong 1y ago
      Thats a bad analogy. A better one is should we check the breaks before (compile time) we start the car and drive down the highway (runtime). At this point you either did check the breaks, or did not. If not you are out of luck if the breaks did infact not work.
kinto 1y ago
Hey, Pyrefly developer here, thanks for trying us out! We're dedicated to providing a great IDE experience, though it does take some time. Please bother us on github / our discord if you have features you want - bug reports / community asks are our biggest priority. - auto import is implemented in Pyrefly: it uses your pyrefly.toml project structure or falls back to your VSCode workspace (up to the first 2500 files). we're happy to fix it for your situation if you want to provide a reproduction - signature/doc when selecting autocomplete options is a known bug [here](https://github.com/facebook/pyrefly/issues/1090 https://github.com/facebook/pyrefly/issues/1090) - go to declaration: I've created an issue for that [here](https://github.com/facebook/pyrefly/issues/1291 https://github.com/facebook/pyrefly/issues/1291), it should be quick. - speed: by far the biggest issue. your problem is likely related to [this](https://github.com/facebook/pyrefly/issues/360 https://github.com/facebook/pyrefly/issues/360) but we need more information to speed it up. we're happy to work with you to to improve this if you're willing to provide a project structure
- sirfz 1y ago
  Hi, thanks for the links and for opening the goto declaration issue (that's awesome). I will try to dedicate more time into my setup and provide feedback where possible. Looking forward for all the new updates!

by sirfz 1y ago

jswny 1y ago

At least for Ty, not sure about the others, it is explicitly for type checking, exposed as an LSP. It’s not trying to compete with full LSP implementations. Most modern editors let you combine multiple LSPs, you shouldn’t think of them as using only one at a time

ehsanu1 1y ago
Do you assign different responsibilities to different LSP servers when there multiple I suppose?
charliermarsh 1y ago
We actually do want ty to be a first-class LSP (i.e., a complete alternative to Pylance and others), and it already supports nearly all of the features you'd expect. I use it as my primary LSP today in lieu of Pylance!
- jswny 1y ago
  Good to know, I had no idea!
sirfz 1y ago
I understand your confusion because at first look it seems like it's just a type checker (same issue with pyrefly and zuban) hence my comment about bringing forward the fact it's a fully featured lsp

deleted 1y ago

[deleted]

screye 1y ago

If ruff & uv have proved anything, it's that a tool that's effortless, a net-positive and fast will get adopted. New typecheckers don't need to be perfect. They need to be good enough, easy to integrate and have low false positives. Sure, they will improve with time, but if feels like a pain then no one will pick it up. Python users are famously averse to tools that slow down their dev cycles, even if it means better long term stability BasedPyright is popular because it comes built-in with Cursor and disappears into the background. I have a positive bias towards Astral figuring it out given their track record. But, none of these tools have reached the point of effortlessness just yet.

phplovesong 1y ago
If typechecking is tongue on cheek, why even bother?
- atoav 1y ago
  If car crashes still kill people, why wear safety belts?
  - tremon 1y ago
    I don't think that's an accurate metaphor. Seatbelts are expressly a runtime solution to car crashes, whereas Python's type checking is a) only done during development (not even during build), and b) completely reliant on third-party tools. If you're looking for a car analogy, I would suggest comparing Python type checking to installing speed cameras on the factory floor.
    - ObscureScience 1y ago
      The analogy would be mandatory inspections of certain components or manufacturing processes to see that rules and specs are followed while assembling.
  - phplovesong 1y ago
    Thats a bad analogy. A better one is should we check the breaks before (compile time) we start the car and drive down the highway (runtime). At this point you either did check the breaks, or did not. If not you are out of luck if the breaks did infact not work.

kinto 1y ago

Hey, Pyrefly developer here, thanks for trying us out! We're dedicated to providing a great IDE experience, though it does take some time. Please bother us on github / our discord if you have features you want - bug reports / community asks are our biggest priority. - auto import is implemented in Pyrefly: it uses your pyrefly.toml project structure or falls back to your VSCode workspace (up to the first 2500 files). we're happy to fix it for your situation if you want to provide a reproduction - signature/doc when selecting autocomplete options is a known bug [here](https://github.com/facebook/pyrefly/issues/1090 https://github.com/facebook/pyrefly/issues/1090) - go to declaration: I've created an issue for that [here](https://github.com/facebook/pyrefly/issues/1291 https://github.com/facebook/pyrefly/issues/1291), it should be quick. - speed: by far the biggest issue. your problem is likely related to [this](https://github.com/facebook/pyrefly/issues/360 https://github.com/facebook/pyrefly/issues/360) but we need more information to speed it up. we're happy to work with you to to improve this if you're willing to provide a project structure

sirfz 1y ago
Hi, thanks for the links and for opening the goto declaration issue (that's awesome). I will try to dedicate more time into my setup and provide feedback where possible. Looking forward for all the new updates!