error Uninitialized attribute [13] in pydantic even though strict mode is not set

[Madhur314e]

Pyre Bug

Bug description I made a class in Pydantic and when i ran pyre check it gave uninitialized attribute [13] error while strict mode was not set to true. Expected behavior As pyre docs states if strict mode is not set to true then pyre check should not throw Uninitialized attribute [13] error.

### My .pyre_configuration file

`{
  
  "source_directories": [
    "api"
  ],
  "search_path":[
    { "site-package": "fastapi" },
    { "site-package": "pydantic" }
  ]
}
`

### My api/main.py file

`from typing import Optional
from fastapi import FastAPI
from pydantic import BaseModel


class Item(BaseModel):
    '''class'''
    name: str
    description: Optional[str] = None
    price: float
    tax: Optional[float] = None


app = FastAPI()


@app.get('/')
def home():
    '''
    home'''
    return {"home": "args"}
`

Output when i ran pyre

ƛ Found 2 type errors!
api/main.py:6:0 Uninitialized attribute [13]: Attribute `name` is declared in class `Item` to have type `str` but is never initialized.
api/main.py:6:0 Uninitialized attribute [13]: Attribute `price` is declared in class `Item` to have type `float` but is never initialized.

[Vegemash]

I am also having this problem. Just being able to silence an error across the project without adding a bunch of ignores would be great. Not everyone can run pyre-upgrade on an entire codebase without making the team unhappy. This is especially grating because there is nothing we can do about these pydantic errors until either pyre adds a special case or a future python version fixes the underlying issue.

[CapCap]

+1 am also having this issue

[m1n9o]

+1 This bug is still there until 21st Mar. Is there any workaround for this?

[adam-mrozik]

+1 bumping the thread, kind of a deal breaker for Pydantic-heavy projects

[grievejia]

I think this requires implementing metaclass support for PEP 681. I'm hoping to find someone to implement this in the next 2 weeks.

[drefrome]

I'm hitting the same issue using django-ninja which is built on top of pydantic. I see that basic PEP 681 support has been added, but I wonder if it's not yet fully supporting pydantic's use of @dataclass_transform to decorate the metaclass of a parent class?

[drefrome]

Having the same problem with pydantic and strawberry even after upgrade to Python 3.11. Has the work mentioned in July happened or is it still not working after the work to support PEP 681?

[cvansteenburg]

I'm using Pyre 0.9.18 with Python 3.11.4 and am experiencing the same problem. Since that SO post I've done a lot of digging but found no scalable solutions.

I see the groundwork has been laid for PEP 681, but wasn't able to determine if it's been implemented.

For the time being, is there a suggested work around? (Or I would be thrilled to find out this is user error ;) ). Thanks!

[zhaodong-wang]

As a workaround, you can write name = Field(...) Then pyre won't complain. Note the three dots means that this Field is required. If not required, just remove the three dots.