Add type hints to builtin models' fields

[flaeppe]

There are quite a bit of changes in here, but it shouldn't produce any different results really.

It mainly allows pyright to also pick up types from the builtin models.

One note about the types for the fields: they have been copied from what has been declared in _pyi_private_set_type and _pyi_private_get_type for each field, so there shouldn't be any difference for mypy.

Related issues

• I opened a discussion a couple of weeks ago: Annotate builtin models' fields with explicit types #2181

[Viicos]

Hopefully this won't play too bad with #1900

[flaeppe]

I'm hoping it should play along since #1900 is more about inferring and defaults?

This instead sets explicit and specific get/set types

[intgr]

This is quite ugly.

Something that I have been pondering about since mypy 1.10 implemented PEP 696 Type Defaults for Type Parameters is: we could add default= to the TypeVars used for model fields.

The downside is that we would need separate TypeVar definitions for most field classes.

# before
class IntegerField(Field[_ST, _GT]):
    _pyi_private_set_type: float | int | str | Combinable
    _pyi_private_get_type: int
    _pyi_lookup_exact_type: str | int

# after
_ST_IntegerField = TypeVar('_ST_IntegerField', default=float | int | str | Combinable)
_GT_IntegerField = TypeVar('_GT_IntegerField', default=int)

class IntegerField(Field[_ST_IntegerField, _GT_IntegerField]):
    _pyi_private_set_type: float | int | str | Combinable
    _pyi_private_get_type: int
    _pyi_lookup_exact_type: str | int

This should improve experience in general for users who don't have the mypy django plugin enabled, and would remove the need for these manual generic arguments:

    password: models.CharField[str | int | Combinable, str]
    last_login: models.DateTimeField[str | datetime | date | Combinable, datetime | None]
    is_active: bool | models.BooleanField[bool | Combinable, bool]

[flaeppe]

I don't mind the generic arguments per se, model fields are generic. And I find it great that we can declare them explicitly for models included in the stubs, because then it becomes very clear what types are allowed.

What I do find off is that e.g. CharField declares int as one of its set types. I know that CharField casts/coerces to a string but to me that looks a bit like support for shotgun parsing.

I wouldn't mind a setup that's using default= either. I looked at that initially but was unsure if we would run into any problems until python/mypy#14851 (comment) has been fixed. I'm happy to change to a default= approach if we don't see any troubles with it.

[flaeppe]

Hm, I don't think we need these through models in the plugin. I think we can add them explicitly in django/contrib/auth/models.py with a @type_check_only decorator

And then also add the following:

class User(AbstractUser):
    id: models.AutoField[str | int | Combinable | None, int]
    pk: models.AutoField[str | int | Combinable | None, int]
+   groups: models.ManyToManyField[Group, User_groups]
+   user_permissions: models.ManyToManyField[Permission, User_user_permissions]