Fix type annotation of ModelMetaclass.__prepare__

[slanzmich]

Change Summary

This fixes a type annotation that was fixed in the typeshed in python/typeshed#11093. type.__prepare__ (and thus ModelMetaclass.__prepare__) must return a mutable mapping. This is because during class creation, that namespace is populated when the class body is executed.

Related issue number

As this change looks rather trivial, I have not created an issue.

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

[slanzmich]

I'm not too familiar with how quickly changes from the typeshed end up in the static type checkers, though. Other than that this is ready, please review.

[codspeed-hq]

CodSpeed Performance Report

Merging #8305 will not alter performance

_{Comparing slanzmich:fix-modelmetaclass-prepare-annotation (ff4bb7d) with main (20c0c6d)}

Summary

✅ 10 untouched benchmarks

[Viicos]

Suggested change

	def __prepare__(cls, *args: Any, **kwargs: Any) -> MutableMapping[str, object]:
	def __prepare__(cls, *args: Any, **kwargs: Any) -> _ModelNamespaceDict:

And make _ModelNamespaceDict parametrized? Could be _ModelNamespaceDict(dict[str, object]) but that doesn't play nice with Python < 3.10, so maybe something like _ModelNamespaceDict(dict, typing.MutableMapping[str, object])?

[slanzmich]

from typing import MutableMapping

class D(dict, MutableMapping[str, float]):
    pass

d = D()
d["k"] = 100
d[2] = 20

does not seem to work, mypy finds no issue with that, while it complains as expected for

class D(dict[str, float]):
    pass

d = D()
d["k"] = 100
d[2] = 20

dict[str, object] works starting with Python 3.9, but not 3.8, which is still supported by pydantic.

[Viicos]

Hum too bad. Subclassing typing.Dict seems to work, although I haven't seen it used this way a lot through Python code. What do you think?

[slanzmich]

I agree, inheriting from typing.Dict works and is probably fine.

After being no longer distracted by this technical issue, I'm wondering whether it makes sense to annotate the return type with a private class, though. Except for the warning, the object returned from __prepare__ will behave exactly like Dict[str, object].

ModelMetaclass is somewhat public (it is type(pydantic.BaseModel)), my gut feeling would be that this exposes a private class.

[Viicos]

Yeah you're probably right, usually the return type hint should reflect precisely the actual type being returned (e.g. type hint list instead of Sequence) but here it makes more sense.

[slanzmich]

Sorry, I'm not too familiar with the code base, so I only noticed this now: _model_construction.py already uses PEP 585 type annotations. For consistency, I assume we can annotate the return type as dict[str, object] without using typing.Dict.

[Viicos]

I'm not too familiar with how quickly changes from the typeshed end up in the static type checkers, though.

pyright is checked on CI, and we should expect a new release very soon (probably before next week).

[sydney-runkle]

@slanzmich,

Looks great, thanks for your contribution! :)

@Viicos, Is it alright if we go ahead and merge this, or do we need to wait on the update to pyright?

[Viicos]

Pyright got updated to 1.1.339 yesterday but typeshed doesn't seem to have been synced in this release. I think it's still fine to merge, pyright can be updated later once a version ships with the typeshed changes