Remove class Meta from Model and Form class stubs

[jorenham]

This fixes several abstract models and model-forms with incorrect annotations for a non-existant Meta type, e.g.

In [1]: from django import forms

In [2]: forms.BaseForm.Meta
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Cell In[2], line 1
----> 1 forms.BaseForm.Meta

AttributeError: type object 'BaseForm' has no attribute 'Meta'

Additionally, the django_stubs_ext.db.models.ModelMeta type alias was added, which can be used as a less-incorrect variant of django_stubs_ext.db.models.TypedModelMeta when annotating the Meta class attribute of a Model, e.g.:

class SupportsModelMetaAndSpam(typing.Protocol):
    Meta: type[django_stubs_ext.db.models.ModelMeta]
    spam: str

[jorenham]

Congratz on the 2000th issue+PR btw 🎉

[sobolevn]

I think the whole reason for this annotation is that all BaseForm subclasses do have Meta attribute. Including user-defined classes.

@flaeppe do you agree with this change?

[flaeppe]

I think the whole reason for this annotation is that all BaseForm subclasses do have Meta attribute. Including user-defined classes.

@flaeppe do you agree with this change?

Yes, I do. But arguably incomplete, since class Meta exists on BaseModelForm and behaves the same way as for Model.Meta: it only exists for subclasses of BaseModelForm.

Ref: https://github.com/django/django/blob/80fe2f439102dc748ff8ddd661d94935915bd3e7/django/forms/models.py#L270-L277

In any case it should be removed from BaseForm.

[jorenham]

There is actually a much larger issue with the way that Meta is currently typed:

from typing import Protocol

class SupportsMeta(Protocol):
    class Meta:
        ...

class MyModel:
    class Meta:
        verbose_name = 'my model'

obj_with_meta: SupportsMeta = MyModel()
"""
Pyright:

Expression of type "MyModel" cannot be assigned to declared type "SupportsMeta"
  "MyModel" is incompatible with protocol "SupportsMeta"
    "Meta" is an incompatible type
      "Untitled.MyModel.Meta" is incompatible with "Untitled.SupportsMeta.Meta"
      Type "type[Untitled.MyModel.Meta]" cannot be assigned to type "type[Untitled.SupportsMeta.Meta]"  (reportAssignmentType)
"""

Solving this appeared to be harder than expected, though... The best I could come up with was this:

from typing import Any, Protocol

class _MetaVerboseName(Protocol):
    verbose_name: str

class _MetaVerboseNamePlural(Protocol):
    verbose_name_plural: str

# ... [one protocol for each allowed Meta attribute]

# emulates type with >=1 of the allowed Meta class attributes
type AnyMeta = _MetaVerboseName | _MetaVerboseNamePlural


# must be made generic, otherwise the meta type won't be covariant
class SupportsMeta[M: AnyMeta](Protocol):
    Meta: type[M]

type SupportsAnyMeta = SupportsMeta[Any]


class MyModel:
    class Meta:
        verbose_name = 'my model'
        verbose_name_plural = 'our models'

obj_with_meta: SupportsAnyMeta = MyModel()

Even in pyright strict mode, this is valid.

[sobolevn]

Yes, using a protocol is a good idea in this case! Thanks for working on this issue :)

[jorenham]

@sobolevn Would you like me to introduce this fix in this PR, or keep it as-is and open up a new one for it?

[sobolevn]

I think we can continue working here, but it is up to you: what feels easier.

[flaeppe]

In the README there's currently a different (but more relaxed?) approach mentioned for model Meta:

https://github.com/typeddjango/django-stubs/?tab=readme-ov-file#type-checking-of-model-meta-attributes

Also, not sure how much it could impact. Not too familiar with nested class definitions and how type checkers like them. But I think Meta could be declared a @property i.e. read only attribute on the protocol?

Quite ingenious idea with the union approach to get rid of the issue supporting partial protocols (wanted to but couldn't find any issue link right now)

[jorenham]

@flaeppe the Protocol solution I proposed would make the TypedModelMeta redundant

[flaeppe]

Yes, I understood that. Just wanted to mention it in case you hadn't seen it.

[jorenham]

I think we can continue working here, but it is up to you: what feels easier.

I'll make the 2000th PR a big one then :)

[jorenham]

Yes, I understood that. Just wanted to mention it in case you hadn't seen it.

Yea thanks for that; it saves me from having to figure out the attribute annotations myself :)

[jorenham]

BTW, here's the pyright-playground link with the Protocol-based Meta solution:

https://pyright-play.net/?pyrightVersion=1.1.353&pythonVersion=3.12&pythonPlatform=Linux&strict=true&locale=en&code=MQAgZgTg9gtiAuBPADgSwHYHMSpsqE8IACtPFAMZQA2AULaBdQIYDOrIAygK7L6GsAsgFN4zABSko5KtQCUALgYgVKpmw4ixS0Kr0gAdEfqMW7EIMSCoAE2HUd%2B9ea3NH%2B1QDdhEAEZRWYQB9dGYYYRAAXhAAchhEEBhbexiTEChfACsggHdUeAALIPDtLl5%2BeCFRZiiLK2TqcTllACI25WJECFRMAvglZQBRAA9kCGF2VCh0dLAEFAiWy2s7ahaQCmZ0dGkQXwiNHvRhGwQoEDt1cdOkZEWePgJK1xblFSX61fXUDgwqPGY8FQvmoETyhRAY2klBoIBaDwqVTEr10qiW1W%2BHC2OHQ-2QgOBoPmdze%2BhaAFV0ED4KCbAZlg16RicL9cbB8UCQWD8gU4ZTqbSDAinkjmEzkaS9AAVBZw27CADa-PygoZq3FzAAuutNttdvsQIdMMcbud5XKFkqqSqTkLyiLXBrtSpxOMKgBBSbG8JUmV3ZqgNqvWiQWDEjDYXAVEDu9CIAA0JDIMLotGcHCCrgAaj5-IEAHJhYSSZOyRS0PTePwBYKhcIKECseAQejpkCZ6o56sFovEajcCDMRpSGQ0cuV3M1kJFoLIfuDhyN5tpIwGEAK6YRKGj6jgAggYTMCi8ofUKA5E4WaqG%2BDN4HceDCTVpYQwbgsR8cc3g3kAPkiACMswIAUBzUGeF6nK4GxmFit7dL4D4TLQ5qxlY17RB2YhdnmwiFuEIAAD7ttmk49uEfYDkO9DKG%2BTZ7BEMDMHYICYMIxzdBQibSKBEB5IEIGMde37TDERAGlQnjMN0WzwGmsFlI8AiuAqggNmhriaiW0JlkoeiuA28qqc%2BKGysKAgaRhimIipaEmfJGh1Cs9h6aobYGRWHggFWuHTgR0RxAkSSrKkXneWRtYznOVG7gFUADokDSsKktAZNkP7FNUDbmZUlliLUar2E0tBAA

[sobolevn]

https://pyright-play.net/?pyrightVersion=1.1.353&pythonVersion=3.12&pythonPlatform=Linux&strict=true&locale=en&code=MQAgZgTg9gtiAuBPADgSwHYHMSpsqE8IACtPFAMZQA2AULaBdQIYDOrIAygK7L6GsAsgFN4zABSko5KtQCUALgYgVKpmw4ixS0Kr0gAdEfqMW7EIMSCoAE2HUd%2B9ea3NH%2B1QDdhEAEZRWYQB9dGYYYRAAXhAAchhEEBhbexiTEChfACsggHdUeAALIPDtLl5%2BeCFRZiiLK2TqcTllACI25WJECFRMAvglZQBRAA9kCGF2VCh0dLAEFAiWy2s7ahaQCmZ0dGkQXwiNHvRhGwQoEDt1cdOkZEWePgJK1xblFSX61fXUDgwqPGY8FQvmoETyhRAY2klBoIBaDwqVTEr10qiW1W%2BHC2OHQ-2QgOBoPmdze%2BhaAFV0ED4KCbAZlg16RicL9cbB8UCQWD8gU4ZTqbSDAinkjmEzkaS9AAVBZw27CADa-PygoZq3FzAAuutNttdvsQIdMMcbud5XKFkqqSqTkLyiLXBrtSpxOMKgBBSbG8JUmV3ZqgNqvWiQWDEjDYXAVEDu9CIAA0JDIMLotGcHCCrgAaj5-IEAHJhYSSZOyRS0PTePwBYKhcIKECseAQejpkCZ6o56sFovEajcCDMRpSGQ0cuV3M1kJFoLIfuDhyN5tpIwGEAK6YRKGj6jgAggYTMCi8ofUKA5E4WaqG%2BDN4HceDCTVpYQwbgsR8cc3g3kAPkiACMswIAUBzUGeF6nK4GxmFit7dL4D4TLQ5qxlY17RB2YhdnmwiFuEIAAD7ttmk49uEfYDkO9DKG%2BTZ7BEMDMHYICYMIxzdBQibSKBEB5IEIGMde37TDERAGlQnjMN0WzwGmsFlI8AiuAqggNmhriaiW0JlkoeiuA28qqc%2BKGysKAgaRhimIipaEmfJGh1Cs9h6aobYGRWHggFWuHTgR0RxAkSSrKkXneWRtYznOVG7tEAAcCWJYl9AZNkP7FNUDbmZUlliLUar2E0tBAA

this is interesting

[jorenham]

@sobolevn I don't see pyright allows int <: str in this case. Adding ClassVar everywhere doesn't help either. Perhaps a bug?

[jorenham]

@sobolevn Ah I understand now. If you remove the correct verbose_name: str, leaving only the verbose_name_plural: int, it'll give an error as expected.

Because of the union; pyright only requires one of the attributes to be correct. I.e. pyright uses short-circuit evaluation on the union. Unfortunately, that's technically correct: Since a hypothetical subtype of _MetaVerboseName could have a verbose_name_plural: int.

I can think of only way around this: Make each individual protocols @final, and additionally create separate @final Protocols for each of the possible combinations.
However, since we have 24 attributes, that would require math.factorial(24) == 620_448_401_733_239_439_360_000 protocols...

[jorenham]

@intgr I don't think it's a good idea to require changes to the implementation for the purposes of typing, of which TypedModelMeta is an example.

I tend to agree with your "all or nothing" mentality regarding typing. But since "all" is practically impossible here, we should look at the remaining $1 + 0.99 \approx 2$ options:

1. Remove Meta altogether (no, not that one; please calm down mr. Zuckerberg...)
2. Scrape Django projects on Github to find the 99% most frequently used Meta attribute combinations, and create union'ed Protocols for those.

My preference would be to go for option 1 first, and place option 1.99 under the "future work" section.

[jorenham]

@jorenham do you want to contribute a pyright CI job? I can be just hidden under || true or allow-errors: true or whatever.

Yea sure, I'll have a look in the coming days

[intgr]

Remove Meta altogether

Indeed. But if you want to propose that, please open a separate PR. As nice as number 2000 is, most of the discussion here would be irrelevant for that proposal.

Model.Meta

As we've established here, having Meta there does nothing for typechecking inner attributes of Meta.

And it seems Model metaclass magic even tries to hide the Meta attribute of models. For example, despite Permission class having explicit class Meta:, it's not actually accessible "from the outside":

>>> from django.contrib.auth.models import Permission
>>> Permission.Meta
AttributeError: type object 'Permission' has no attribute 'Meta'
>>> Permission().Meta
AttributeError: 'Permission' object has no attribute 'Meta'

In almost all situations, the "correct" approach would be to access Model._meta anyway, not .Meta. (Despite being named with underscore, _meta is stable public API in Django).

So 👍 from me. Does anyone see any downsides or issues that could cause?

BaseForm.Meta

I haven't used Django forms for years, so I don't have an informed position on this. Is class Meta required or optional in forms? Is there an equivalent of _meta in form classes? Is the form.Meta attribute accessible from the outside?

[intgr]

Scrape Django projects on Github to find the 99% most frequently used Meta attribute combinations, and create union'ed Protocols for those.

👎 I don't think what will work. We don't want to flag the remaining 1% as errors if they're actually correct. And if we add a "loose protocol" to the union for those use cases, then it also spoils typechecking for the remaining 99%. Besides that, it would be an extremely ugly hack.

[sobolevn]

Yes, I also agree. Hacking something should be justified: right now using Protocols here does not seem like a proper solution. We need something else.

[jorenham]

@intgr model forms also cast the same black magic spell as models on Meta to turn it into _meta. Here's the incantation: https://github.com/django/django/blob/5.0.3/django/forms/models.py#L277

[jorenham]

But you make fair points @intgr and @sobolevn ; I'll remove the messy Meta magic.

But for the sake of backwards compatibility; I assume that we're gonna want to keep TypedModelMeta for now, right? And perhaps mark it as deprecated, e.g. with @typing_extensions.deprecated?

[intgr]

A few suggestions.

I didn't notice before that you had updated this. I was expecting a separate PR ("if you want to propose that, please open a separate PR"). But no big deal; since you already pushed here, no need for additional bureaucracy.

[intgr]

I assume that we're gonna want to keep TypedModelMeta for now, right?

Yes, I haven't seen any reasons to remove it.

[jorenham]

A few suggestions.

I didn't notice before that you had updated this. I was expecting a separate PR ("if you want to propose that, please open a separate PR"). But no big deal; since you already pushed here, no need for additional bureaucracy.

Oh woops I didn't notice. But either way, it would've been sad if the 2000th PR wouldn't have made it :)

[intgr]

Awesome, thanks!