AIaitchnyu·May 14, 2026
Wish Django Stubs dont need a Mypy plugin
https://github.com/typeddjango/django-stubs
In Pyrefly v1.0 is here (fast type checker and language server for Python)typeddjango
django-stubs
Python2018–2026
typeddjango / django-stubs
django-stubs
PEP-484 stubs for Django
10Distinct people
12Mentions
0Explicit recommenders
2KGitHub stars
What to know before exploring
What it is
PEP-484 stubs for Django
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year12 dated mentions
Observed mentions: 2018-08-01 18:32:08 UTC to 2026-05-14 08:22:06 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
12 sourcesThere's a really nice typing plug-in for mypy that's been around a long time:
https://github.com/typeddjango/django-stubs
It is very disappointing that these new type checkers don't support plug-ins, so things like django-stubs aren't possible. That means you're stuck with whatever is delivered with these new type checkers. It must be really difficult since none of them support plug-ins. Some of these newer type checkers promise support for Django, but you're stuck with what they (will) have on offer. Also, you'll likely want typing for other libs you might use.
In Comparing Python Type Checkers: Typing Spec ConformanceRelatedly, in case it's useful, the django-stubs package provides mypy compatible type stubs for Django:
https://github.com/typeddjango/django-stubs
In Plain – a web framework for building products with PythonWill django-stubs work with other typecheckers?
Tangential, I'm waiting for Edgedb to become next SQL so all ORM moats like Django's are drained.
https://github.com/typeddjango/django-stubs
In "We're building a new static type checker for Python"Agree with this.
All type checkers other than mypy (e.g. pyright, intellij) have ignored the level of plugin support necessary to make django work well, and so they are DOA for any large existing django codebase. Unless ruff decides to support such a dynamic interface as mypy's, it'll fare no better.
We use mypy with [django-stubs](https://github.com/typeddjango/django-stubs) which works ok nowadays.
There was an effort to create a typechecking plugin interface for dataclass-style transforms for python type checkers, but what was merged was so lacking that one couldn't even make something close to django-stubs with it.
In "We're building a new static type checker for Python"To get the type checker to work with Django you need to install django-stubs[1]. It works great with mypy, but should also work well with pyright.
[1]: https://github.com/typeddjango/django-stubs
In Ask HN: Which Python type checker should I use?Pyright doesn't work with Django, as Django's so dynamic that it requires a plugin to infer all types correctly. Sadly, even mypy with plugins is a mess to get set up in vscode, especially if you want it to use the same config as you use for ci checks from the command line.
We use mypy + [django-stubs](https://github.com/typeddjango/django-stubs) (in a huge Django + drf project at day job) which includes a plugin for mypy allowing it to recognize all reverse relations and manager methods. Mypy is still really rough around the edges. The cli args are poorly documented, and how they correspond to declarations in a mypy.ini / pyproject.toml is mysterious. Match-statements still have bugs even a year after release. Exclusion of untyped / partially typed files and packages we've had to solve with grep filtering mypy's output for our whiteliste
Read the rest
d set of files, as it's been unable to separate properly between errors you care about (in your own codebase) and errors in others code (dependencies, untypable dynamic python packages etc).
The largest issue IMO is that mypy tried to adapt a java / OOP style way of type system onto python, instead of recognizing the language's real power within duck typing and passing structural types around. Typescript chose the right approach here, modelling javascript the way it is actually written, favoring structural over nominal typing, instead of the archaic and now left-behind way of Java-style OOP that has influenced mypy.
There was a recently accepted PEP which allowed for limited dataclass transforms, enough to cover the @attr.s usecase for both mypy and pyright, but nowhere near expressive enough to cover django's models and ORM sadly. It's probably impossible / undesirable to allow for such rich plugins, so i see the future for proper pluginless typing to be more akin to how pydantic / normal dataclasses solve typing, by starting with a specification of the types, deriving its runtime implementation, instead of plugins having to reverse the type representation of a custom DSL.
You can annotate the manager and get some typing help in the editor. And there’s django-stubs which helps a little when running mypy. It’s not as good as pycharm though.
https://github.com/typeddjango/django-stubs/tree/master
In Boring Python: Code quality> Yes, there are type stubs for these libraries but they’re either forced to be more strict, preventing use of dynamism, or opt for being less strict but allowing you to use all the library features, at the cost of safety.
There are type stubs for Django that somewhat avoid these compromises: https://github.com/typeddjango/django-stubs
To be able to do this they have to use a Mypy plugin though. And even then it's still far from perfect.
In Python 3.11.0 finalMypy together with this plug-in gives you typing for django. https://github.com/TypedDjango/django-stubs
In Is Rust Web Yet?There's a DEP discussion going on at https://github.com/django/deps/pull/65. Though I kind of gave up on it for now, I don't believe it'll be accepted in the current state of mypy and typing ecosystem.
Try 'django-stubs' mentioned above too https://github.com/typeddjango/django-stubs, it's mostly complete. Mypy plugin inside takes care of a lot of stuff.
Disclaimer: I'm a creator of the 'django-stubs'
In Django 3There's been some work to add type-hinting to Django if that helps.
Check out:
https://github.com/TypedDjango/django-stubs#django-stubs
https://gitter.im/mypy-django/Lobby
In Django 2.1 released