Due to a bug in mypy 0.940 (typeddjango#870), we made two changes in typeddjango#871:

• pinned mypy==0.931 in requirements.txt (for running our tests);
• bounded mypy<0.940 in setup.py (for downstream users).

After the mypy bug was quickly fixed upstream in 0.941, our setup.py
bound has been repeatedly raised but not removed (typeddjango#886, typeddjango#939, typeddjango#973).
The only changes in those commits have been to the precise wording of
error messages expected in our tests.  Those wording changes don’t
impact compatibility for downstream users, so it should be safe to go
back to allowing them to upgrade mypy independently.

Since mypy doesn’t yet guarantee backwards compatibility in the plugin
API (although in practice it has rarely been an issue), add a
django-stubs[compatible-mypy] extra for users who prefer a known-good
version of mypy even if it’s a little out of date.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>

* Move mypy version upper bound to a [compatible-mypy] extra

Due to a bug in mypy 0.940 (#870), we made two changes in #871:

• pinned mypy==0.931 in requirements.txt (for running our tests);
• bounded mypy<0.940 in setup.py (for downstream users).

After the mypy bug was quickly fixed upstream in 0.941, our setup.py
bound has been repeatedly raised but not removed (#886, #939, #973).
The only changes in those commits have been to the precise wording of
error messages expected in our tests.  Those wording changes don’t
impact compatibility for downstream users, so it should be safe to go
back to allowing them to upgrade mypy independently.

Since mypy doesn’t yet guarantee backwards compatibility in the plugin
API (although in practice it has rarely been an issue), add a
django-stubs[compatible-mypy] extra for users who prefer a known-good
version of mypy even if it’s a little out of date.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>

* Update setup.py

Co-authored-by: Nikita Sobolev <mail@sobolevn.me>