Override dataclass_transform behavior for RootModel

[Viicos]

Change Summary

Fixes #7418.

Seems to work as expected on mypy (you can experiment here).

For pyright, see the comment below.

There's some mypy tests for root models, but they seem to only run on mypy 1.0.1 and with the plugin.

Related issue number

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

Selected Reviewer: @hramezani

[codspeed-hq]

CodSpeed Performance Report

Merging #8163 will not alter performance

_{Comparing Viicos:root-model-positional (9d9b971) with main (2e459bb)}

Summary

✅ 10 untouched benchmarks

[Viicos]

I don't know if this is still required in the mypy plugin if this PR gets merged?

pydantic/pydantic/mypy.py

Lines 860 to 862 in 24272b4

	if is_root_model:
	# convert root argument to positional argument
	args[0].kind = ARG_POS if args[0].kind == ARG_NAMED else ARG_OPT

[Viicos]

Although this works with mypy (e.g. creating subclass of RootModel will allow positional argument for root), pyright does not support it (see: microsoft/pyright#6489 (comment)).

One workaround would be to have a metaclass for RootModel, subclassing ModelMetaclass, and we could set dataclass_transform.kw_only_default=False on this metaclass.

A fix to support having dataclass_transform applied directly on RootModel is also available, so this is up to you (see issue on pyright for more context).

[Viicos]

Please review

[dmontagu]

My initial reaction to this is that:

• If it is possible to do something with a sub-metaclass of ModelMetaclass, I would make a _RootModelMetaclass in an if TYPE_CHECKING: block, and in the else:, just set it to be exactly ModelMetaclass. Something like:

diff --git a/pydantic/root_model.py b/pydantic/root_model.py
diff --git a/pydantic/root_model.py b/pydantic/root_model.py
index 97381233..a0c0bf00 100644
--- a/pydantic/root_model.py
+++ b/pydantic/root_model.py
@@ -8,15 +8,23 @@ from copy import copy, deepcopy
 from pydantic_core import PydanticUndefined
 
 from . import PydanticUserError
-from ._internal import _repr
+from ._internal import _model_construction, _repr
 from .main import BaseModel, _object_setattr
 
 if typing.TYPE_CHECKING:
-    from typing import Any
+    from typing import Any, dataclass_transform
 
     from typing_extensions import Literal
 
+    from .fields import Field as PydanticModelField
+
+    @dataclass_transform(kw_only_default=False, field_specifiers=(PydanticModelField,))
+    class _RootModelMetaclass(_model_construction.ModelMetaclass, typing.Generic[typing.Any]):
+        ...
+
     Model = typing.TypeVar('Model', bound='BaseModel')
+else:
+    _RootModelMetaclass = _model_construction.ModelMetaclass
 
 
 __all__ = ('RootModel',)
@@ -25,7 +33,7 @@ __all__ = ('RootModel',)
 RootModelRootType = typing.TypeVar('RootModelRootType')
 
 
-class RootModel(BaseModel, typing.Generic[RootModelRootType]):
+class RootModel(BaseModel, typing.Generic[RootModelRootType], metaclass=_RootModelMetaclass):
     """Usage docs: https://docs.pydantic.dev/2.6/concepts/models/#rootmodel-and-custom-root-types
 
     A Pydantic `BaseModel` for the root object of the model.

I think it's best to do it in the if TYPE_CHECKING: block to keep things as performant as possible and minimize the risk that there is any possible impact on runtime behavior of existing code.

• If this causes issues with mypy or pyright (I haven't checked if it does, but I did check that all (non-mypy) tests pass with the diff above), I think we should maybe go back and ask for the change to pyright to make the change in pydantic unnecessary.

[dmontagu]

Regarding the point:

I don't know if this is still required in the mypy plugin if this PR gets merged?

I would suggest we remove that logic branch as part of this PR if we can and mypy still handles root models correctly (due to the change to the dataclass_transform). I strongly suspect we have code in one of the existing mypy tests that checks that you don't get an error with RootModel if you use a positional argument to the __init__, but it would be good to confirm this prior to merging changes to the plugin code (assuming those changes don't cause any tests to fail).

[Viicos]

I would make a _RootModelMetaclass in an if TYPE_CHECKING: block

Neat, tested and it works as expected both pyright and mypy.

I strongly suspect we have code in one of the existing mypy tests that checks that you don't get an error with RootModel if you use a positional argument

It seems there is a test, but running only with the mypy plugin. I'll add the test without the plugin and then see how I can drop the special case currently implemented.

[Viicos]

mypy support for dataclass_transform isn't really good in 1.0.1 iirc, hence the errors

[sydney-runkle]

@Viicos, can't we remove these now that you added back support for 1.0.1?

[Viicos]

Please review

[sydney-runkle]

@Viicos,

Looks great otherwise, just wondering if we can avoid reintroducing mypy errors in 1.0.1 if possible.

[sydney-runkle]

@Viicos,

If we add this back, do we get no errors for mypy 1.0.1 as well as all of the other mypy versions currently tested?

If so, I'd prefer to do that + add a note about the special case for 1.0.1.

[sydney-runkle]

Or if necessary, wrap this check in a block that checks the mypy version

[sydney-runkle]

Looks great otherwise. Please see my question on the 1.0.1 tests. Otherwise, ready to approve and merge 👍

[sydney-runkle]

@Viicos, can't we remove these now that you added back support for 1.0.1?

[sydney-runkle]

Great! Approved.