Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong error report in PydanticSettings #6099

Closed
laipz8200 opened this issue Jul 5, 2024 · 3 comments
Closed

Wrong error report in PydanticSettings #6099

laipz8200 opened this issue Jul 5, 2024 · 3 comments
Assignees

Comments

@laipz8200
Copy link

Environment data

  • Language Server version: 2024.6.1
  • OS and version: darwin arm64
  • Python version (and distribution if applicable, e.g. Anaconda): 3.10.14
  • python.analysis.indexing: true
  • python.analysis.typeCheckingMode: standard

Code Snippet

from pydantic_settings import BaseSettings


class Settings(BaseSettings):
    pass


config = Settings(_env_file='.env')

Repro Steps

  1. Just use my code, its also from https://docs.pydantic.dev/latest/concepts/pydantic_settings/#dotenv-env-support

Expected behavior

Should not report any error.

Here is __init__ from BaseSettings:

image

and DotenvType is Union[Path, str, List[Union[Path, str]], Tuple[Union[Path, str], ...]]

Actual behavior

image

Logs

XXX
@github-actions github-actions bot added the needs repro Issue has not been reproduced yet label Jul 5, 2024
@erictraut
Copy link
Contributor

Pyright's behavior here is correct based on the type information provided to it and the rules spelled out in the Python typing spec.

The Settings class derives from BaseModel, which is decorated with @dataclass_transform. That means it acts like a dataclass. If there is no explicit __init__ method provided by the class, an __init__ method will be synthesized based on the fields in the class definition. Since there are no fields defined in this class, type checkers assume that the synthesized __init__ has no parameters. It appears that the runtime behavior of pydantic's BaseModel deviates from this behavior.

For comparison, other type checkers like mypy generate the same error in this case.

To "fix" this, issue, pydantic's implementation of the BaseModel would need to change or the Python typing spec would need to change. If you'd like to pursue a change in pydantic, you could post to the pydantic issue tracker. If you'd like to pursue a change in the typing spec, you could post to the Python typing forum.

As a workaround, you could define a minimal __init__ method in your class that calls through to the parent's __init__ method.

from pydantic_settings import BaseSettings
from pydantic_settings.sources import DotenvType

class Settings(BaseSettings):
    def __init__(self, _env_file: DotenvType) -> None:
        super().__init__(_env_file=_env_file)

config = Settings(_env_file=".env")

@debonte debonte added external bug and removed needs repro Issue has not been reproduced yet labels Jul 5, 2024
@debonte debonte closed this as completed Jul 5, 2024
@laipz8200
Copy link
Author

Hi @erictraut! I reached out to the pydantic-settings team, and they informed me that they have a pydantic.mypy extension to address this issue. I understand that Pylance has its own type checker. Is there anything we can do to solve this? Alternatively, is there a way to use Mypy's extension?

@erictraut
Copy link
Contributor

erictraut commented Jul 9, 2024

Mypy's extensions are specific to mypy, so if you want to use the mypy extension for pydantic, you'll need to install mypy and use it as your type checker.

Pylance is built on pyright, which is a standards-based static type checker. Pyright doesn't have an extension model, and it's unlikely that we'd ever add one because such an approach has many downsides. Our approach has been to work with library authors to standardize behaviors and codify them in the ever-expanding Python typing specification. This approach has enabled us to support much (but not all) of pydantic's functionality.

In cases where pydantic deviates from behaviors that deviate from, or are not supported by, the typing standards, there are often ways to work around the issue if you want your code to work with pyright and pylance. See my response above for such a suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants