* Fix CI
* Fix CI
* Fix CI
* Fix CI
* APply black
* APply black
* Fix mypy
* Fix mypy errors in django-stubs
* Fix format
* Fix plugin
* Do not patch builtins by default
* Fix mypy
* Only run mypy on 3.10 for now
* Only run mypy on 3.10 for now
* WHAT THE HELL
* Enable strict mode in mypy
* Enable strict mode in mypy
* Fix tests
* Fix tests
* Debug
* Debug
* Fix tests
* Fix tests
* Add TYPE_CHECKING debug
* Caching maybe?
* Caching maybe?
* Try explicit `${{ matrix.python-version }}`
* Remove debug
* Fix typing
* Finally
* 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>
- Updates test_model_field_classes_from_existing_locations to account
for the behaviour change in https://github.com/python/mypy/pull/12663
- Bumps the version of django-stubs for a new release
* Bump mypy to 0.95x
* Remove the * for inferred types
There was an upstream change (https://github.com/python/mypy/pull/12459)
to remove * from inferred types in the reveal_type output.
As we are asserting the * to exist, all the test cases are now failing
on the 0.950 release. Removing the expected * to mirror the upstream
behaviour change should resolve the test failures.
* Adds support for pyproject.toml files
Since mypy 0.900 the pyproject.toml files are supported.
This PR adds a support for it. It searchs for a `tool.django-stubs` section. This is an example configuration:
```
[tool.django-stubs]
django_settings_module = "config.settings.local"
```
Fixes#638
* Added TOML tests
* Use textwrap.dedent instead of trying to manually replace spaces
* Allow Collection for 'fields' and 'exclude' of form model helpers (#637)
There are several functions and classes in `django.forms.models` that
take a `fields` or `exclude` argument. Previously, `Sequence` was used
to annotate these, but the code of Django (I checked version 3.2.4)
doesn't require `__getitem__()` to be implemented, so requiring
`Collection` instead is sufficient.
The practical advantage of requiring `Collection` is that a set, such
as the key set of a dictionary, can be passed without first having to
convert it to a list or tuple.
* Pin mypy to below version 0.900
* Remove Callable for 'fields' and 'exclude' of form model helpers
I cannot find any support for callables for these two arguments in
the code or in the documentation.
* Update setup.py
Co-authored-by: Nikita Sobolev <mail@sobolevn.me>
* run black
* create monkeypatching function for adding get_item dunder
* whoops i forgot the test
* change the name in INSTALLED_APPS to make test pass
* turn the whole thing into a proper package
* move django_stubs_ext to requirements.txt
* also install requirements.txt
* attempt to fix pre-commit
* numerous small code review fixes
* fix dependency issues
* small dependency fixes
* configure proper license file location
* add the rest of the monkeypatching
* use strict mypy
* update contributing with a note monkeypatching generics
* copy release script from parent package
