mypy "Explicit "Any" is not allowed" error when extending BaseModel

[DetachHead]

Initial Checks

• I confirm that I'm using Pydantic V2

Description

in my codebase, we ban the Any type using the --disallow-any-explicit rule (along with all the other rules that ban Any in other contexts). when extending BaseModel, mypy complains with a no-any-explicit error.

this is annoying because it means we have to add a type:ignore comment on all of our classes that use BaseModel.

related issue: the dataclass decorator had the same problem (#4355), which i fixed in #4356. but i can't seem to figure out what's causing it in this case. i think it may be related to the pydantic mypy plugin?

Example Code

from pydantic import BaseModel

class Foo(BaseModel): # error: Explicit "Any" is not allowed (no-any-explicit)
    ...

Python, Pydantic & OS Version

pydantic version: 2.5.3
        pydantic-core version: 2.14.6
          pydantic-core build: profile=release pgo=true
                 install path: C:\Users\user\project\.venv\Lib\site-packages\pydantic
               python version: 3.12.0 (tags/v3.12.0:0fb18b0, Oct  2 2023, 13:03:39) [MSC v.1935 64 bit (AMD64)]
                     platform: Windows-11-10.0.22621-SP0
             related packages: typing_extensions-4.11.0

[DetachHead]

BaseModels with {"extra": "forbid"} do not have this issue:

class Foo(BaseModel): # no error
    model_config = ConfigDict(extra="forbid")

however, the mypy plugin does not seem to work when the config comes from a variable:

from pydantic import BaseModel, ConfigDict

default_config = ConfigDict(extra="forbid")

class Foo(BaseModel): # error: Explicit "Any" is not allowed (no-any-explicit)
    model_config = default_config

---

edit:

actually, even with {"extra": "forbid"}, they're still broken if there are any fields on them at all:

class Foo(BaseModel): # error
    model_config = ConfigDict(extra="forbid")
    foo: int # error goes away if you remove this

---

edit 2:

seems like configuring the mypy plugin with these options fixes it:

[tool.pydantic-mypy]
init_forbid_extra = true
init_typed = true

[sydney-runkle]

@DetachHead,

Hmm, thanks for reporting this. @dmontagu might have a better idea of how the mypy plugin relates to this issue. Let's see what he thinks!

[dmontagu]

This makes sense to me — what's happening is that by default we add a __init__ with signature def __init__(self, field_1: Any, field_2: Any, **kwargs: Any):. If you set init_forbid_extra = True in the config, we remove the **kwargs, and if you set init_typed = True in the config, we change the field Anys to their type hints.

The reason we allow Any by default (which I think now that @dataclass_transform has gotten traction and behaves that way, we should consider reversing the default behavior of this in v3) is that the validation coming from pydantic will allow you to pass values that aren't already the correct type, such as a string for a datetime, and I think it annoyed people a while ago that that would be reported as a type error even though pydantic would validate the input properly.

If you were so inclined, I would welcome a PR to the docs explaining that, if you use the --disallow-any-explicit mypy config setting, you need to enable these strict mode settings for the pydantic mypy plugin or you will get errors for all of your models.