Char fields with blank=True set should not be considered nullable in the
context of values() and values_list() querysets.
I'm also not a huge fan of the way these fields are made optional in the
constructur to the model classes, it feels like it would be better to
mark the arguments as having a default value, rather than allow sending
in None, but I'd rather keep this fix small and look at the overall
problem at a later point.
Pyright complains about `response.cookies` because the generic type isn't known. `str` may or may not be the correct type to use here. Something should be set here.
* Set type of default `django.core.cache` to `BaseCache`
- The previous type `ConnectionProxy` is just a proxy class, thus
revealing `Any` for _all_ cache methods
* fixup! Set type of default `django.core.cache` to `BaseCache`
If a django model has a Manager class that cannot be resolved statically
(if it is generated in a way where we cannot import it, like `objects =
my_manager_factory()`), we fallback to the default related manager, so
you at least get a base level of working type checking.
* Fix manager types scope
* Restore incremental mode and mention in developer docs
* Separate dev mypy config and regular one
* Document config files usage
* 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>
* Fix BaseModelFormSet.save_m2m: accept `self`
Before it would result in the following when calling it:
> Attribute function "save_m2m" with type "Callable[[], None]" does not accept self argument [misc]
* fixup! Fix BaseModelFormSet.save_m2m: accept `self`
- 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
When fetching a related field in a values_list queryset Django will
return the object primary key, not model instances as was previously
what the mypy plugin assumed.
* Fix error when nesting OuterRef expressions
OuterRef(OuterRef("my_field")) is a valid expression in nested
subqueries. Mypy would complain that OuterRef was an incompatible type
because OuterRef is typed to only accept str.
* Only fix for OuterRef
* OuterRef is not guaranteed to be resolved to ResolvedOuterRef
* Fix type of min_value and max_value on DecimalField
These should at the very least allow Decimals. Technically you can send
in anything that's comparable to a Decimal, but I'm not sure if it makes
sense to allow floats. Could allow both ints and Decimals I guess?
* Allow ints and floats as well
* Update django-stubs/forms/fields.pyi
* Update django-stubs/forms/fields.pyi
Co-authored-by: Nikita Sobolev <mail@sobolevn.me>
* 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.
Since PR 909, SimpleTestCase.client.get() etc methods return a class that no longer derives from `HttpResponse`, but instead `HttpResponseBase`, the `assert*` methods taking response should be updated as well.
Discovered while trying to update djangorestframework-stubs to django-stubs as of master.
django-stubs still supports Python 3.7, but the `/` positional-only parameter syntax is supported only in Python 3.8+.
Not sure why this error wasn't caught in CI.
