Autocomplete for vscode does not register `Field` defaults when using positional argument

Checks

• I added a descriptive title to this issue
• I have searched (google, github) for similar issues and couldn’t find anything
• I have read and followed the docs and still think this is a bug

Bug

Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":

             pydantic version: 1.9.0
            pydantic compiled: True
                 install path: /Users/.../.../venv/lib/python3.8/site-packages/pydantic
               python version: 3.8.6 (default, Feb  5 2021, 13:58:38)  [Clang 12.0.0 (clang-1200.0.32.21)]
                     platform: macOS-10.16-x86_64-i386-64bit
     optional deps. installed: ['typing-extensions']

from pydantic import BaseModel, Field


class Thing(BaseModel):
    x: bool = Field(False, description="hello")
    y: float

# this will give a pylance error saying "Argument missing for parameter x"
thing = Thing(y=4.5)

class Thing2(BaseModel):
    x: bool = Field(default=False, description="hello")
    y: float

# this is fine
thing = Thing2(y=4.5)

With screenshots we can see the error:

… and without the error

So it looks like there is a bug in the autocomplete when using a positional argument for default as opposed to a keyword argument.

I am not hugely familiar with the new dataclass transform but it looks like it requires that default be a keyword argument and not a positional argument.

I see that this is actually on purpose but I’m not sure why. If this is needed (and I’m sure it it) then adding a warning or note to the documentation would be helpful.

[marianhlavac]

@samuelcolvin I’m sorry for misinterpreting it as a Pydantic bug, but I hope it’s understandable, given the situation — the behaviour started after merging #2721, and it seems that this use case slipped through the code review and tests before merging the PR. Thank you for contacting Eric to clarify where the problem lies, this helped a great deal to understand what’s really going on.

I don’t think complaining about this or pointing out how many old open PRs there are is going to help you…

I think this was unnecessarily defensive. The new version brought a lot of frustration to pyright users (we’re not talking just about IDE), effectively making them stay on Python 3.9 (# type: ignore is not an acceptable solution, sorry) if they want to continue using both pydantic and pyright, for almost four months.

Don’t get me wrong, I love Pydantic and I cannot imagine having Python projects without pydantic in their lists of dependencies, and I appreciate the work done by you and other contributors. Pointing out stale PRs was never meant to seek attention to this issue, rather than express the concerns that any new contribution might get lost.
Maybe letting others help with maintaining the repository (I’m not sure how many maintainers there are for this repository) could also help clear up the backlogs and bring similar issues to motion faster. I doubt there would be lack of people willing to help, as this is an excellent project with many people who love it.

[marianhlavac]

@rlkennedyreid When something exists, doesn’t necessarily means it should be recklessly used. # type: ignore exists for daunting edge cases in a specific cases, and their count in the codebase should be kept to a minimum. Extensive use of type ignores defeats the purpose of typehinting in Python. Having 10 type ignores in codebase doesn’t justify adding another 40 of them.