DetachHead / basedpyright

pyright fork with various type checking improvements, improved vscode support and pylance features built into the language server
https://docs.basedpyright.com
Other
1.19k stars 21 forks source link

Basedpyright showing more errors than pyright in a Django project #681

Closed DMunkei closed 1 month ago

DMunkei commented 1 month ago

I've got a Django project that makes use of the Django RESTFramework and Django version 4.2.

In order to help my editor NeoVim to get the proper typing, I've installed the type stubs:

django-stubs              5.0.4
django-stubs-ext          5.0.4
djangorestframework       3.14.0
djangorestframework-stubs 3.15.1
Django                    4.2.9

Now when I am inside of a models.py file and declare my model class I am getting

Type of "foo" is partially unknown
     Type of "foo" is "DateTimeField[Unknown, Unknown]" [reportUnknownVariableType]
Type of "bar" is partially unknown
     Type of "bar" is "CharField[Unknown, Unknown]" [reportUnknownVariableType]

I've also tried running both pyright and basedpyright directly from the terminal on the exact same file as above. And the outputs are as follows.

Pyright
➜ ~/.local/share/nvim/mason/bin/pyright api/komponente/models.py
0 errors, 0 warnings, 0 informations

basedpyright
  /Users/xcv/Development/qwe/api/komponente/models.py:37:5 - error: Type of "foo" is partially unknown
    Type of "foo" is "CharField[Unknown, Unknown]" (reportUnknownVariableType)
22 errors, 0 warnings, 0 notes

I have also made sure that I am already running my virtual environment before executing the command to make sure that the type stubs are collected.

This is only reported when I have basedpyright running. Inside of the same exact file pyright doesn't seem to have an issue with it.

I stumbled upon basedpyright by chance and have to say, it's definetly cooler when it comes to the additional information it's providing the editor. And would like to keep using it :D.

Any idea why this might be the case?

I'm happy to provide additional information if necessary. Thanks :)

DetachHead commented 1 month ago

this is probably because basedpyright enables all diagnostic rules by default (my reasoning behind this decision is explained here).

if you want the same defaults as pyright, you can set typeCheckingMode to "standard":

# pyproject.toml
[tool.basedpyright]
typeCheckingMode = "standard"

more info about the configuration is available here

DMunkei commented 1 month ago

I also thought that this might be the case since it's set to all per default. I've changed it to standard inside of my lsp.lua file where I can set other options. The effect was still the same.

I had a slight error in my config. The pyright configuration inside of Mason has the setting key under python.

The basedpyright configuration has the settings key under basedpyright. So I was using the incorrect key to configure basedpyright from within my lsp.lua file.

Here's the excerpt from the Mason lsp documentation.

Pyright

python = {
    analysis = {
      autoSearchPaths = true,
      diagnosticMode = "openFilesOnly",
      useLibraryCodeForTypes = true
    }
  }

basedpyright

  basedpyright = {     <--- This was my mistake, had python instead
    analysis = {
      autoSearchPaths = true,
      diagnosticMode = "openFilesOnly",
      useLibraryCodeForTypes = true
    }
  }

Setting the typeCheckingMode = "standard" has the same output as the pyright standard setting. Vice-versa, if you set pyright to strict it shows the same errors as basedpyright.

It's working as intended now.