Improve type of Token.for_user to allow subclasses

[sterliakov]

The same approach is already used in BlacklistMixin. The issue with existing Token return type can be demonstrated by

from django.contrib.auth.models import User
from rest_framework_simplejwt.tokens import RefreshToken

user: User
token = RefreshToken.for_user(user)
token.access_token  # E: "Token" has no attribute "access_token"  [attr-defined]

[50-Course]

Hello @sterliakov,
Thank you for this patch. This approach demonstrate a forward-thinking approach. In this case, modifying the "Token" user to generic type [T] address the issue in a clear concise way since, a similar pattern had already appeared in the codebase.

While there is no breaking changes at the moment, would you be interested to write tests for this functionality focusing on its impact on the Token class itself and the subclass, RefreshToken?

[sterliakov]

Hi! I'd be interested in contributing to type checking of this project in Jan.

There are other typing issues I spotted (e.g. TokenObtainSerializer should be generic in token type to have correct get_token return type), and I have a typed codebase (not OSS, unfortunately) where many components of this package are extended (so some issues will pop up when I upgrade).

Regarding the tests - it would be not as straightforward, unfortunately, due to django-stubs complicated nature that requires code import and execution. Some aspects can be tested trivially, though, and I am willing to cover such patterns. Typechecking tests are usually of shape "here's the file, run mypy on it and check output" (you can find examples e.g. here).

[sterliakov]

Ough. I failed to notice this initially, but I also want to add mypy to CI very much: types seem to be not checked at all now.

[50-Course]

I would re-review after the holidays! Happy new year in advance @sterliakov 🌟

[50-Course]

Hi @sterliakov, reopening discussion on this patch, we could work with mypy on a separate MR

[50-Course]

LGTM!