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

Mypy regression - Missing named argument #5190

Closed
6 of 15 tasks
Tracked by #5192
pykler opened this issue Mar 14, 2023 · 3 comments
Closed
6 of 15 tasks
Tracked by #5192

Mypy regression - Missing named argument #5190

pykler opened this issue Mar 14, 2023 · 3 comments
Assignees
Labels
bug V1 Bug related to Pydantic V1.X unconfirmed Bug not yet confirmed as valid/applicable

Comments

@pykler
Copy link

pykler commented Mar 14, 2023

Initial Checks

  • I have searched GitHub for a duplicate issue and I'm sure this is something new
  • I have searched Google & StackOverflow for a solution and couldn't find anything
  • I have read and followed the docs and still think this is a bug
  • I am confident that the issue is with pydantic (not my code, or another library in the ecosystem like FastAPI or mypy)

Description

pydantic version 1.10.6 + mypy 1.1.1 + mypy plugin causes error with previously ok code.
Note: mypy plugin is irrelevant, and does not affect the output in this usecase

Using Field with a description on an optional Field, without an explicit default=None, used to work

$ mypy sample.py 
sample.py:10: error: Missing named argument "bar" for "Sample"  [call-arg]
Found 1 error in 1 file (checked 1 source file)

Error started happening with pydantic 1.10.4, version 1.10.2 does not have this issue
versions >1.10.2 now require the explicit default=None on Optional fields.

This seems like a bug, if not please advise.

Example Code

from typing import Optional
from pydantic import BaseModel, Field


class Sample(BaseModel):
    foo: str
    bar: Optional[str] = Field(description="optional")


Sample(foo="hello world")

Python, Pydantic & OS Version

pydantic version: 1.10.6
            pydantic compiled: True
                 install path: /home/hatem/projects/inventory_service/venv/lib/python3.8/site-packages/pydantic
               python version: 3.8.10 (default, Sep 28 2021, 16:10:42)  [GCC 9.3.0]
                     platform: Linux-5.11.0-37-generic-x86_64-with-glibc2.29
     optional deps. installed: ['dotenv', 'typing-extensions']

Affected Components

@pykler pykler added bug V1 Bug related to Pydantic V1.X unconfirmed Bug not yet confirmed as valid/applicable labels Mar 14, 2023
@dmontagu dmontagu self-assigned this Mar 14, 2023
@samuelcolvin
Copy link
Member

see #5192

@dmontagu
Copy link
Contributor

This appears to have been introduced by using @dataclass_transform on the metaclass, and the reason that it works in 1.10.2 is because that version used the keyword argument field_descriptors instead of the correct field_specifiers.

I'm not sure how involved it will be to fix this properly while retaining the @dataclass_transform behavior; the good news is that in v2 this shouldn't be an issue because we no longer set an implicit default for Optional/Any fields.

Does anyone know why the keyword argument was field_descriptors before? Was that just a typo?

@dmontagu
Copy link
Contributor

Seems there was some logic issues in the plugin that meant it wouldn't work correctly if you set a Field as the default but didn't specify default or default_factory. The dataclass_transform thing was just hiding the issue. I've got a fix coming shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug V1 Bug related to Pydantic V1.X unconfirmed Bug not yet confirmed as valid/applicable
Projects
None yet
Development

No branches or pull requests

3 participants