Hello all! I’m a happy Neolvim using Pythonista and had been using pyright for years.
Recently, I saw that basedpyright is a fork of the original project, and their doc cites a lack of responsiveness to PRs on the part of the pyright developers and lack of velocity around considering and adding new features.
Does anyone have any insight into the situation?
Are there compelling reasons you choose one or the other?
Is there a way we could resolve and de-escalate the fork?
I feel like this is a comparatively niche project and it might benefit the community to have one place to look rather than two.
I’m not sure about the specifics about PRs that were not accepted, but basedpyright supports inlay hints and semantic tokens, while pyright does not support that nor do they have any plans to support it. According to Support inlayhint feature · Issue #4325 · microsoft/pyright · GitHub, to get those features, one needs to use the proprietary pylance LSP, which AFAIK doesn’t work outside of Visual Studio Code.
The tl;dr is that pyright doesn’t like explicit namespace packages (ones that have __path__ = __import__("pkgutil").extend_path(__path__, __name__)) and as a result Eric’s answer is a “your code is wrong, change it”
Dynamic (runtime) manipulation of __path__ isn’t supported by pyright or other static analysis tools. You’ll need to find another solution if you want this to work.
(It’s also not true about “other static analysis tools” – isort at least supports namespace packages)
Which is technically true, but user hostile and not reflecting the reality of how python projects are working. I’d describe Eric’s view point as a “Type Prescriptivist” – i.e. he has a firm view that only one way of doing things is right, and the practicalities of common code be damned.