files=wwau,../../shared
ignore_missing_imports=true
plugins =
mypy_django_plugin.main
django_settings_module = your_django_settings"
i've got a class-based login view that overrides FormView and uses an AuthenticationForm. the idiomatic django way to use this is to override form_valid to log the user in:
def form_valid(self, form):
auth_login(self.request, form.get_user())the issue is that FormView uses a BaseForm which doesn't have a get_user method, and casting form to AuthenticationForm violates liskov
is there a better, type-safe way to log in the user without querying the database?
I have a function that is written before the model:
def a_func(name: str) -> Model1:
return ContentType.objects.get(
model=name,
).model_class()
class Model1(Model):
...
The question is why this works:
def a_func(name: str) -> 'Model1' //wrapped with string literal
but not without the string literal?
as_manager/as_queryset support.
@kalekseev thanks for your reply! Agree, this option would be great. In that case, there would be no field checks for this manager, right? Tbh, it looks that creating your own manager with a copypasted queryset methods seems to help.
class Q(models.Queryset[User]):
def active(): ..
class M(models.Manager[User]):
def active():
return self.get_queryset().active()This is a little bit annoying, but in that case, it looks that mypy is able to detect errors here.
How hard do you think it will be to add support for as.manager()?
@fatalispm yes, with that patch your managers will be typed as Any. Of course you can provide types by hands but I don't think it's an acceptable method for a big codebase.
How hard do you think it will be to add support for as.manager()?
I think previous attempt typeddjango/django-stubs#272 failed because of bug (limitation) in mypy python/mypy#8359
@kalekseev That's interesting. I didn't mean providing types by hand, but using Manager that will duplicate queryset methods.. (e.g living without queryset.as_manager()). This adds boilerplate, but on the other hand, it can potentially eliminate a few bugs?
So do you think that get_dynamic_class_hook will fix the problem with .as_manager()?
as_queryset (I tested with django-stubs 0.7.0). Perhaps this should be documented, as it seems like a pretty common pitfall.from django.db import models
class MyModelQuerySet(models.QuerySet):
def foo(): pass
MyModelManager = models.Manager.from_queryset(MyModelQuerySet)
class MyModel(models.Model):
objects = MyModelManager()
def use_my_model():
m = MyModel.objects.get(id=1)
reveal_type(m) # MyModel
1 reply
fuu: "QuerySet[FUUModel]"
fuu: "Model[FUUModel]"
def send(self, *, communication: "Model[Communication]", schedule: "Model[CommunicationSchedule]"):
...
# a.py
from typing import TYPE_CHECKING
if TYPE_CHECKING:
from .b import B
class A:
b: "B"
def __init__(self, b: "B"):
self.b = b
Model, I got this error: "Type[ModelBase]" is incompatible with "Type[Model]" in the line where I use my decorator. Something like this:@my_decorator
class MyModel(models.Model):
...
Hey all. Has anyone tried using these type stubs with a different type checker, like pyright? I understand that django-stubs ships with a mypy plugin, and the README says it doesn't make sense to try to use the stubs without mypy
That said, I was hoping I could get some of the benefits of using the type stubs in django-stubs without using the mypy plugin
@sobolevn Is it possible to get a useful subset of the benefits of the stubs with a type checker other than mypy?
1 reply
