Hi pyrefly team,
After recent retesting, I’ve found pyrefly quite aligned with my expectations from a typechecker in terms of false positives, false negatives, and speed. Good job.
So I decided to test the LSP in VS Code.
I find the LSP experience is still quite rough, and even a week later I’m finding it problematic to use. Many points are well addressed in pyright/basedpyright/pycharm:
np/pd/plt do not auto-import the right libraries. It’s a convenience feature, but an extremely common one.- When I type
json and ask for auto-import, the json library isn’t at the top. List ordering for auto-import doesn’t make sense to me most of the time. In pyright it is ~15%, but in pyrefly it is >50%.
- When I start typing
import pandas as pd and hit Enter, I don’t end up on the next line; instead, the line is modified to import pandas as pdb. Editing aliases like this is meaningfully wrong.
- The speed of pyrefly detecting unused/undeclared variables — changing color / underlining quickly — is cool. But unfortunately, every keystroke can also change inferred types, and they change the line length multiple times a second. A small artificial example is below:
def f(x: dict[str, tuple[int, str, bytes, list[bool]]]):
return [
(my_int, bool_item, our_bytes, your_str)
for key, values in x.items()
for (my_int, your_str, our_bytes, bool_list) in values
for bool_item in bool_list
]Try taking just the first 5 elements of x.items(), e.g. by wrapping it into list(x.items())[:5] — you’ll see that multiple lines change their length while typing, and eyes can’t comfortably track this. Same if you somehow modify values to func(values).
There should be some limit on the speed of updates in the proximity of the edit area. One solution could be fading types to highlight that they are incorrect, but not changing the width immediately. There are other solutions.
Thank you! LMK if you need additional feedback.
Hi pyrefly team,
After recent retesting, I’ve found pyrefly quite aligned with my expectations from a typechecker in terms of false positives, false negatives, and speed. Good job.
So I decided to test the LSP in VS Code.
I find the LSP experience is still quite rough, and even a week later I’m finding it problematic to use. Many points are well addressed in pyright/basedpyright/pycharm:
np/pd/pltdo not auto-import the right libraries. It’s a convenience feature, but an extremely common one.jsonand ask for auto-import, thejsonlibrary isn’t at the top. List ordering for auto-import doesn’t make sense to me most of the time. In pyright it is ~15%, but in pyrefly it is >50%.import pandas as pdand hit Enter, I don’t end up on the next line; instead, the line is modified toimport pandas as pdb. Editing aliases like this is meaningfully wrong.Try taking just the first 5 elements of
x.items(), e.g. by wrapping it intolist(x.items())[:5]— you’ll see that multiple lines change their length while typing, and eyes can’t comfortably track this. Same if you somehow modifyvaluestofunc(values).There should be some limit on the speed of updates in the proximity of the edit area. One solution could be fading types to highlight that they are incorrect, but not changing the width immediately. There are other solutions.
Thank you! LMK if you need additional feedback.