Python lsp: Pyright isn't good

[lctzz540]

Check for existing issues

• Completed

Describe the feature

it should be pylsp. The pyright has issues about recognize libraries installed

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[JosephTLyons]

Yeah, pyright has been a big source of pain for us in the Zed-Python intersection. I think we should def swap out to something better. I've not heard of pylsp, but we should def add it to the list of ones to check out:

• pylsp
• pylyzer
• astral.sh will hopefully build a language server in Rust

We are working on language plugins at the moment, so, in the not-so-distant future, someone can just add these servers as plugins, but I do think we should swap out our provided one for a bettter one.

[plattenschieber]

Yeah, pyright has been a big source of pain for us in the Zed-Python intersection. I think we should def swap out to something better. I've not heard of pylsp, but we should def add it to the list of ones to check out:

• pylsp
• pylyzer
• astral.sh will hopefully build a language server in Rust

We are working on language plugins at the moment, so, in the not-so-distant future, someone can just add these servers as plugins, but I do think we should swap out our provided one for a bettter one.

Indeed they did build a language server protocol for Ruff already ruff-lsp @JosephTLyons 🔥

[JosephTLyons]

Yeah, pyright has been a big source of pain for us in the Zed-Python intersection. I think we should def swap out to something better. I've not heard of pylsp, but we should def add it to the list of ones to check out:

• pylsp
• pylyzer
• astral.sh will hopefully build a language server in Rust

We are working on language plugins at the moment, so, in the not-so-distant future, someone can just add these servers as plugins, but I do think we should swap out our provided one for a bettter one.

Indeed they did build a language server protocol for Ruff already ruff-lsp @JosephTLyons 🔥

AFAICT, ruff-lsp only support formatting and linting as of right now, as they haven't gotten to building things out like go to def and auto-completion, but I read they will be doing that at some point.

[failable]

https://github.com/pappasam/jedi-language-server

[JacobGoldenArt]

Yeah. I love Zed but when I open a Python project it's just strange. I will activate my .venv in my project directory and the script will run but when you look at the python file the imports are all red and can't be resolved.

[JacobGoldenArt]

See that python-dotenv is installed, along with pydantic in my env - (pip list) but I guess pyright is not checking for packages in the project-directory/.venv ???

[failable]

You need this file.

$ cat pyrightconfig.json
{
  "venvPath": ".",
  "venv": ".venv"
}

[Moshyfawn]

There's an issue #8541 about resolving modules with Pyright.

[newtome8888]

I see this problem last for months, but there's still no real solution?

[JosephTLyons]

You need this file.

$ cat pyrightconfig.json
{
  "venvPath": ".",
  "venv": ".venv"
}

This should actually solve the problem - for some reason, during the migration of our documentation, we lost our Python docs that mentions this config file. I've quickly dumped the old Python docs contents into the configuration section of our website, here. I need to bring back more documentation, so I will organize this better later on.

As a side note, I want to say that we are going to be doing more for Python here shortly - we recognize just how important this language is, being one of the top most-used languages, and we want to improve for Python devs in Zed.

[newtome8888]

You need this file.

$ cat pyrightconfig.json
{
  "venvPath": ".",
  "venv": ".venv"
}

This should actually solve the problem - for some reason, during the migration of our documentation, we lost our Python docs that mentions this config file. I've quickly dumped the old Python docs contents into the configuration section of our website, here. I need to bring back more documentation, so I will organize this better later on.

As a side note, I want to say that we are going to be doing more for Python here shortly - we recognize just how important this language is, being one of the top most-used languages, and we want to improve for Python devs in Zed.

I tried it, but no luck. I use poetry in my python project, does it matter?

[collinsinclair]

To add to the corpus of Pyright issues, in is_24hour = models.BooleanField(default=False), False is red-underlined for

Argument of type "Literal[False]" cannot be assigned to parameter "default" of type "type[NOT_PROVIDED]" in function "_init_" Type "Literal[False]" cannot be assigned to type "type[NOT_PROVIDED]"

Additionally, in def __str__(self):, __str__ is red-underlined for

Method "_str_" overrides class "Model" in an incompatible manner Return type mismatch: base method returns type "str", override returns type "CharField" "CharField" is incompatible with "str"

I have done no custom configuration. I believe these shouldn't be showing issues as they work as expected and are standard practices.

[r-cha]

I tried it, but no luck. I use poetry in my python project, does it matter?

@newtome8888 run poetry env info to find the path to your virtualenv, then add that to your pyrightconfig. Worth noting, this path will be different per machine, so don't add pyrightconfig.json to any version control. Mine looks something like this:

{
  "venvPath": "/Users/username/Library/Caches/pypoetry/virtualenvs",
  "venv": "projectname-p0LYZhue-py3.11"
}

[JosephTLyons]

I tried it, but no luck. I use poetry in my python project, does it matter?

@newtome8888 run poetry env info to find the path to your virtualenv, then add that to your pyrightconfig. Worth noting, this path will be different per machine, so don't add pyrightconfig.json to any version control. Mine looks something like this:

{
  "venvPath": "/Users/username/Library/Caches/pypoetry/virtualenvs",
  "venv": "projectname-p0LYZhue-py3.11"
}

Just to mention, there is a setting in poetry tells poetry to install the venv within the project:

• https://python-poetry.org/docs/configuration#virtualenvsin-project

Which would stabilize where the pyrightconfig.json points to, when running the project on multiple machines.

[failable]

Using pyright is literally painful.

[ryukinix]

There is any simple way to replace pyright with mypy? Pyright being the default is kinda a deal breaker for me.

[osiewicz]

You can use mypy with pylsp that's the other language server provided out of the box.

[smparekh]

for macOS using pylsp with ruff, here is my setup:

...
  "languages": {
    "Python": {
      "language_servers": ["pylsp", "!pyright", "..."],
      "preferred_line_length": 120
    }
  },
  "lsp": {
    "pylsp": {
      "binary": {
        "path": "/Users/<USERNAME>/.local/bin/pylsp"
      },
      "settings": {
        "plugins": {
          "ruff": {
            "enabled": true,
            "formatEnabled": true,
            "lineLength": 120,
            "targetVersion": "py311"
          }
        }
      }
    },
...

Install python-lsp-ruff:

pipx install python-lsp-ruff --include-deps

[g0di]

Furthermore from my perspective having the formatter (Ruff) in parallel to the LSP is a more flexible experience than having the formatter hierarchically under the the LSP (as a plugin). But I am not well acquainted with the technicalities of this topic so perhaps there is a performance/scaling consideration that I'm not aware of.

I can rely on that. I've give a try to python-lsp-ruff plugin to use only pylsp as my one and only language server in Zed for python and it appeared that formatting (and code fixes) were lot more slower (more than a second) compared to using directly the ruff lsp (instantaneous) next to pylsp or pyright for handling the rest. I don't know if I'm the only one noticing this.

By the way, I actually have to use pyright, pylsp and ruff servers next to each others in my Zed config because using only pylsp and ruff does not provide any autocompletion anymore... Not sure why. So pyright gives me autocompletion (and more), pylsp gives me mypy type checking (through plugin) and ruff gives me linting and formatting.

Not sure if this is the best config but it works as intended. Just my 2 cents experience.

[TIAcode]

I have Zed with basedpyright & ruff stuck showing Python 2.7.18

settings.json:
...
"language_servers": ["ruff", "basedpyright", "!pyright"],
...
pyrightconfig.json:
{
  "typeCheckingMode": "strict",
  "reportUnknownParameterType": true,
  "reportUnknownArgumentType": true,
  "reportUnknownMemberType": true,
  "venv": ".venv",
  "venvPath": "/home/user/projectdir/"
}

Everything is working correctly - imports from the venv work, errors are correct, but at bottom right of Zed it always shows 2.7.18 instead of 3.12.8 that's used in the venv

[ds-sebastian]

This was released recently:
https://github.com/astral-sh/ty

[ryukinix]

Probably is better than pyright, after all I can't think anything worse than pyright for this. It would be nice if ty was eventually a potential alternative for zed. Em ter., 13 de mai. de 2025 21:07, Sebastian ***@***.***> escreveu:

…

This was released recently: https://github.com/astral-sh/ty — Reply to this email directly, view it on GitHub <#23376 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2J57UVOYM3QZESIVRUUWL26KCLNAVCNFSM6AAAAABYDXFFX6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMJTG43TMMI> . You are receiving this because you commented.Message ID: ***@***.***>

[Tom-Boscher]

It seems that at this time there is no extension for ty in Zed.

[jhelgert]

Besides Astral's ty, there's also Meta's pyrefly, another type checker and language server written in Rust that might be worth keeping an eye on.

[strangemonad]

@jhelgert FWIW, pyrefly is a rewrite of pyre, which was originally much more focused on static checking of security issues rather than being used as an LSP

[NathanielH-snek]

I have an extension for Ty but I'm not going to open a PR until Ty is usable. I'm expecting things will change to some extent.

[lucianosrp]

There's an extension for ty also here.

[culebron]

I'm trying Zed again, this time for Python, and the linter is just out of its mind, yelling at everything.

A function returns [sometype | None], I take return_value.property - NO, CAN'T READ ATTRIBUTE OF NONE!!!!

But wait a min, we're not in Rust, I can't "unpack" the val.

Another example: maptlotlib returns something it can't understand => yell at every matplotlib function/method call. See the screenshot. Can't get attribute for the class -> THE METHOD IS ILLEGAL, DROP IT!!!!

And this one is just hilarious: the paranoid linter thinks map is a built-in map, and I must provide a function. In reality, it's Pandas .map that takes dict or Series.

How can I get rid of this thing and bring pyflakes?

[edit] solved, config in the next post.

[lucaspar]

on the first instance, you should check if mod is None before using it. That's how you "unpack" it.

[lucaspar]

I'd enable inlay hints to see what the types are being inferred as. The other 2 examples seem to be caused by variables being a different type than what you're expecting.

[culebron]

@lucaspar: the code works perfectly and processes files and draws charts with matplotlib, so I definitely know the types that I'm getting. It's pyright that is rust-like cautious.

Another example: numpy's maximum_filter functions return type is (NDArray[float64] | NDArray[Any] | NDArray[generic] | Unknown). Pyright then doesn't allow me to add/subtract the return value with another NDArray[float64].

[lucaspar]

There's a difference between inferred and runtime types. It might work when you run it, but because of the dynamic nature of the language, if you want a better level of type safety sometimes you need to nudge the type checker with a cast or add type checks that would otherwise not be needed. This is notoriously common for libraries that have been around longer than most type checking features in Python.

[culebron]

Ok, that's clear. Well, I don't want to compensate linter's incompatibility with the established libraries, with my own time, babysitting every function call.

[culebron]

Solved the problem with pyright/pyflakes.

• pip install python-lsp-server
• settings.json:

{
        ... other settings ...
	"languages": {
		"Python": {
			"language_servers": ["pylsp"],
		}
	},
	"lsp": {
		"pylsp": {
			"settings": {
				"plugins": {
					"pyflakes": {
						"enabled": true
					},
					"pycodestyle": {
						"enabled": true,
						"ignore": ["W191"]
					}
				}
			}
		}
	}
}

List of possible settings in pylsp.

[twelvedogs]

i'm sure pyright has it's supporters but it's really rough having to learn how to configure something you hate just to get it to go away

[ryukinix]

pyright make zed just useless for python, but pylsp worked fine. I use this in my settings after instaling pylsp (similar #23376 (comment)) on the host system:

  "lsp": {
    "pylsp": {
      "settings": {
        "plugins": {
          "mypy": {
            "enabled": true
          },
          "flake8": {
            "enabled": true
          },
          "pycodestyle": {
            "enabled": false
          },
          "pyflakes": {
            "enabled": false
          }
        }
      }
    }
  },

[isty2e]

Having used several python lsps, basedpyright and zuban were my choices. ty is still premature, and pyrefly was too resource heavy for me. Zuban is written in Rust as well, mypy compatible, and passes more entries in pyting conformance test. If it were not for import-not-found issue with some packages, I'd probably used it in production already.

[failable]

Been using Jedi for years in the old days, zuban seems promising!