pyrefly

hi - pyrefly developer here. this was an oversight made by me a while ago during our beta launch. thanks for reporting. we have a full response [here](https://github.com/facebook/pyrefly/issues/3292#issuecomment...) in the github issue

Pyrefly is Meta's new Python type checker and VS Code extension, released earlier this year. While auditing the VSIX before installing it, I found that on activation it silently writes `disableLanguageServices = true` to the user's global settings for three named extensions: basedpyright, windsurfpyright, and cursorpyright. The write uses `ConfigurationTarget.Global`, so it affects all workspaces. There is no `deactivate()` cleanup, so the setting persists after Pyrefly is uninstalled. This was verified by live reproduction: installed Pyrefly alongside basedpyright, opened a Python file, and observed the key appear in `settings.json`. Uninstalled Pyrefly — key remained, basedpyright still broken. The code is in plain TypeScript in the public repo (`lsp/src/extension-interop.ts`), added December 2025. This isn't obfuscated or hidden — it j

(pyrefly maintainer here) If you haven't already, please file an issue for that crash on the [Pyrefly repo](https://github.com/facebook/pyrefly) as well :)

Hey, Pyrefly developer here, thanks for trying us out! Thanks for bearing with us with these issues you're experiencing while we're still in alpha. We're planning on adding unreachable code diagnostics soon (github issue [here](https://github.com/facebook/pyrefly/issues/1292)). These come for free with Pyright so we don't want to regress features. I'm happy to help diagnose/fix your autocomplete issue: it should work on modules. If you want to provide details here, on [discord](https://discord.gg/Cf7mFQtW7W), or as a Github issue (github/discord preferred) we'll fix it for you + anyone else with the problem.

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) - go to declaration: I've created an issue for that [here](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/fac

The weird Literal promotion makes pyrefly unusable for me, except if I'd avoid Literal types: https://github.com/facebook/pyrefly/issues/742

> it does not actually cover what rules you can check or infer from type hints Indeed this is the cause of maybe 30% of the warnings I'm seeing… items being added to lists or dicts in some place (or something else making it infer a container type), and pyrefly then refusing other types getting added elsewhere. The most "egregious" one I saw was: def something(x: list[str]) -> str: foo = [] for i in x: foo.append(i) return "".join(foo) Where it complains: ERROR Argument `str` is not assignable to parameter `object` with type `LiteralString` in function `list.append` [bad-argument-type] --> test.py:4:20 4 | foo.append(i) Edit: now that I have posted it, this might actually be a bug in the .join type annotation… or something Edit: nah, it's the loop (and the LiteralString variant of .join is ju

(Pyrefly dev here) Thanks for trying it out! If you have any feedback or bug reports, please don't hesitate to file issues on GitHub or find us on Discord. We have some open issues for SQLAlchemy (like [1]). I'm definitely curious to hear if there are any gaps from your perspective, having an already strictly-typed codebase. 1. https://github.com/facebook/pyrefly/issues/954

in the related FAQ https://github.com/google/pytype/issues/1925 they point explicitly to the future: > What alternatives can I consider? There are four Python static type checkers that can be considered: mypy and Pyright have been released to the community for a while and have well established user bases. Pyrefly, ty were announced recently at PyCon US 2025 and are in active development stage in the current time of August 2025 when this was written. mypy - https://github.com/python/mypy Pyright - https://github.com/microsoft/pyright Pyrefly - https://github.com/facebook/pyrefly ty - https://github.com/astral-sh/ty

https://github.com/facebook/pyrefly/releases Pyrefly v0.29.0 Status : ALPHA