Pylance "unreachable code" on ModelViewSet's get_queryset and get_object methods (and those using them)

[the-middium]

Hello,

After coming back to a project that uses DRF, after a while, I've noticed that Pylance marks ModelViewSet's .get_object(...) method as being -> NoReturn. After checking, it seems that GenericAPIView.queryset being set to None is causing Pylance to think that the non-None assertion in .get_queryset(...) is triggered and that the code stops there (that method is marked by Pylance as returning Never).

After adding the type annotation QuerySet | None to .queryset, these issues appear to have been resolved.

[itzzdev09]

Your diagnosis holds up. The class attribute carries no annotation at all, so the declared type is inferred purely from the assignment:

>>> [l.strip() for l in inspect.getsource(GenericAPIView).splitlines() if l.strip().startswith("queryset")][0]
'queryset = None'
>>> GenericAPIView.__annotations__
{}

With queryset inferred as None, assert self.queryset is not None narrows it to Never, the assert is treated as always failing, and everything after it — including get_object() — is flagged unreachable. Adding QuerySet | None fixes it because it gives the narrowing something to survive into, which is why your workaround works.

DRF doesn't ship inline types or a py.typed marker, so this isn't a case of stubs disagreeing with the source — there's nothing for Pylance to go on beyond the assignment. The usual answer is to install the external stubs rather than annotate in-place:

pip install djangorestframework-stubs

which declares these attributes properly and stops the false positives across the whole class, not just the two methods you patched. Worth noting they're maintained separately from DRF, so their coverage can lag releases.

If you'd rather not add the dependency, subclassing is a bit less invasive than editing site-packages:

class BaseViewSet(ModelViewSet):
    queryset: QuerySet | None = None

Confirmed on DRF 3.18.0 / Django 5.2.17.