5.2.3 regression with `TypedModelMeta` and mutable override

[sobolevn]

This code causes two errors when mutable-override code is enabled:

from django.db import models

class BlogPost(models.Model):
    body = models.TextField()

    class Meta:
        verbose_name = 'BlogPost'  # E: Covariant override of a mutable attribute (base class "TypedModelMeta" defined the type as "str | _StrPromise", expression has type "str")  [mutable-override]
        verbose_name_plural = 'BlogPosts'  # E: Covariant override of a mutable attribute (base class "TypedModelMeta" defined the type as "str | _StrPromise", expression has type "str")  [mutable-override]

This is not ideal :(
Since there are lots of verbose_name definitions in my project and it does not use _() at all.

Ignoring all lines is rather hard to do manually, disabling this check is also rather sad :(

[UnknownPlatypus]

Since there are lots of verbose_name definitions in my project and it does not use _() at all.

You would have the same issue with a StrPromise.

class A:
    foo: str | StrPromise
    
class B(A):
    foo = _("ffo") # E: Covariant override of a mutable attribute (base class "A" defined the type as "str | StrPromise", expression has type "StrPromise")  [mutable-override]
    
class C(A):
    foo = "asdadada" # E: Covariant override of a mutable attribute (base class "A" defined the type as "str | StrPromise", expression has type "str")  [mutable-override]

I'm really not sure what mypy expect in this case (and found some similar skepticism in the PR adding support for the mutable-override check).

pyright and ty are fine with that, but mypy is not

---

That appart, we could probably have another approach in the plugin by type-checking symbol manually instead of relying on mypy automatic check with the current approach (And what we recommend in the readme which suffer from the same issue.

[sobolevn]

Let's maybe do it like this:

• Iterate through all currently set attributes in our custom Meta type
• If any of its parents contains the same key, do the type check
• If our attribute is not a subtype of the parent one - raise an error

In this case it would be a bit more work, but no mutable-override problems :)

WDYT?

[sobolevn]

The only question is when to catch this moment in our plugin 🤔

[UnknownPlatypus]

If any of its parents contains the same key, do the type check

We would check against the type we declare in the stub no ? Because in your scenario, we don't have the TypedModelMeta in the mro.

(Btw non valid attributes make runtime crash, so it we be nice to raise errors here too)

[sobolevn]

Yeah, I mean not "parent" but "virtual parent", sorry for the confusion :)

[UnknownPlatypus]

Probably manageable but mypy behaviour is not ideal here. There are probably similar issues with the Django admin that works similarly with such "config" classes