Apply strict=True to __init__ in mypy plugin

[kc0506]

Change Summary

I've added a feature to pydantic-mypy where type annotations for __init__ will apply to fields with strict=True, even when init_typed set to False. Additionally, if model_config['strict'] = True is set for a model, then all fields will be typed in __init__ unless overridden with Field(strict=True).

Currently, this feature only works with a: int = Field(strict=True) and not with a: Annotated[int, Field(strict=True)] or a: Annotated[int, Strict(strict=True)]. It is also implemented only for __init__ and not for validate_call or other methods.

Example Code

class Model(BaseModel):
    a: int
    b: int = Field(strict=True)
    c: int = Field(strict=False)

# expected mypy error: b
Model(a='1', b='2', c='3')


class ModelStrictMode(BaseModel):
    model_config = {'strict': True}

    a: int
    b: int = Field(strict=True)
    c: int = Field(strict=False)

# expected mypy error: a, b
ModelStrictMode(a='1', b='2', c='3')

Related issue number

fix #9997

Checklist

• The pull request title is a good summary of the changes - it will be used in the changelog
• Unit tests for the changes exist
• Tests pass on CI
• Documentation reflects the changes where applicable
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

[codspeed-hq]

CodSpeed Performance Report

Merging #9998 will not alter performance

_{Comparing kc0506:add-mypy-strict-field (ae95cd1) with main (5ec9845)}

Summary

✅ 14 untouched benchmarks

[dmontagu]

This looks great, the only concern I have, as noted in the issue #9997, is whether we might under some circumstances emit type errors for valid (and non-pathological) strict mode usage where it does not currently emit type errors. If that's the case, I'd feel better making this opt-in via a new plugin strictness setting.

The important question is — are there any patterns of usage where you might realistically have a strict-mode model (or field) where it is convenient to not get type errors for passing in values that are not validated.

I'll note that since @dataclass_transform will give errors any time you provide a non-valid value, anyone not using the mypy plugin will probably always get type errors for providing invalid values (whether in strict mode or not); I would consider that a fairly strong argument for moving the mypy plugin in a stricter-typed __init__ direction — for the sake of improved consistency with the rest of the python ecosystem.

I'll see what @sydney-runkle thinks, but I think I'm good merging this unless there's some obvious/common/problematic scenario that this introduces issues for. I can't think of one, and for what it's worth I'd also be okay merging and rolling this back if such issues get reported (and reworking to require opting into this behavior via some config setting).

[sydney-runkle]

I'll see what @sydney-runkle thinks, but I think I'm good merging this unless there's some obvious/common/problematic scenario that this introduces issues for. I can't think of one, and for what it's worth I'd also be okay merging and rolling this back if such issues get reported (and reworking to require opting into this behavior via some config setting).

Agreed, happy to merge this as is for now. I think it's fair to say that our mypy plugin falls a bit under the experimental umbrella. Additionally, I think as long as we're striving for more consistency with the general Python ecosystem, then I feel alright making a change that's not opt-in here. If we discover any truly compelling cases down the line, we can consider an opt in approach.