Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

create and re-use TypeAliases and TypeVars for "user" and "any user" #2384

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

create and re-use TypeAliases and TypeVars for "user" and "any user" #2384

wants to merge 1 commit into from

Conversation

terencehonles
Copy link
Contributor

@terencehonles terencehonles commented Sep 27, 2024 •
edited
Loading

I have made things!

This change also adds a few user type vars and alises to cover the common use cases of User, User | AnonymousUser, and their TypeVar forms for using in generic contexts.

sobolevn
sobolevn reviewed Sep 27, 2024
View reviewed changes
Copy link
Member

@sobolevn sobolevn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally - looks great! Just one note

django-stubs/contrib/auth/models.pyi Outdated
# This is our "placeholder" type the mypy plugin refines to configured 'AUTH_USER_MODEL'
# wherever it is used as a type. The most recognised example of this is (probably)
# `HttpRequest.user`
_User: TypeAlias = AbstractUser
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's move this before _AnyUser, no need to create an extra inference cycle.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

flaeppe
flaeppe reviewed Sep 27, 2024
View reviewed changes
Copy link
Member

@flaeppe flaeppe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should change the base class to be AbstractUser. This is a section of what the "Specifying a custom user model" says in the docs:

[...] The easiest way to construct a compliant custom user model is to inherit from AbstractBaseUser. AbstractBaseUser provides the core implementation of a user model, including hashed passwords and tokenized password resets. [...]

https://docs.djangoproject.com/en/5.1/topics/auth/customizing/#specifying-a-custom-user-model

@sobolevn
Copy link
Member

I don't think we should change the base class to be AbstractUser.

As far as I understand, this is not the base class, this is the default type, unless AUTH_USER_MODEL is specified.

@terencehonles
Copy link
Contributor Author

That's interesting that they suggest that... The issue is that AbstractBaseUser does not include the PermissionsMixin and if we shouldn't be requiring AbstractUser we may want to create a type checking only protocol (not sure if that's easy to do as a subtype and I can play around with that).

It does look like there's probably some complications if we move the base class up (subclasses of AbstractBaseUser will not work as subclasses of AbstractUser), so I'll look into this more, but since the plugin is patching the type based on AUTH_USER_MODEL it may only be a problem if you aren't using mypy or haven't configured the plugin.

@terencehonles
update default AUTH_USER_MODEL to be AbstractUser and reuse a…
06a4f41 
…liases

This change updates the previous ``AUTH_USER_MODEL`` placeholder alias
to default to ``AbstractUser`` instead of ``AbstractBaseUser`` which
does not include the ``PermissionsMixin``, so that the type alias works
better even without the mypy plugin.

This change also adds a few user type vars and alises to cover the
common use cases of ``User``, ``User | AnonymousUser``, and their
``TypeVar`` forms for using in generic contexts.
@terencehonles
Copy link
Contributor Author

I don't think we should change the base class to be AbstractUser. This is a section of what the "Specifying a custom user model" says in the docs:

I rolled back the change since it does affect a user who subclasses AbstractBaseUser based on the documentation. I can look into the permissions issue a little if I have time, but I had already fixed our custom plugin not pulling the right model so the replacement is working for us and we're not hit by AbstractBaseUser not implementing permissions.

This change still adds some helpful aliases so it can get merged in and the follow-up can be done independently.

@terencehonles terencehonles changed the title update default AUTH_USER_MODEL to be AbstractUser and reuse aliases create and re-use TypeAliases and TypeVars for User and AnyUser Oct 1, 2024
@terencehonles terencehonles changed the title create and re-use TypeAliases and TypeVars for User and AnyUser create and re-use TypeAliases and TypeVars for "user" and "any user" Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@sobolevn sobolevn sobolevn left review comments

@flaeppe flaeppe flaeppe left review comments

Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@terencehonles @sobolevn @flaeppe