* 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>
Add the missing attribute django.http.response.StreamingHttpResponse.streaming .
This is actually done by moving the attribute from HttpResponse to the base class HttpResponseBase.
The real Django source code declares this attribute on HttpResponse and StreamingHttpResponse, however that's only because Django doesn't have type hints. The right place for the type hint is on the base class HttpResponseBase, since all instances of that base class are actually instances of HttpResponse or StreamingHttpResponse or a subclass of those two classes. So it's guaranteed that every HttpResponseBase instance has the attribute.
Fixes bug #629.
* fix(ResolverMatch): Added _func_path
ResolverMatch class in Django contains _func_path variable and it will get initialized in init method whatever the condition, so it should be added in type stubs as well. https://github.com/django/django/blob/main/django/urls/resolvers.py#L48
* Update resolvers.pyi
Co-authored-by: Nikita Sobolev <mail@sobolevn.me>
This monkey patching will only work when using Python 3.7+, which
introduced the `__class_getitem__` magic method. This tripped me up for
a while as I was on Python 3.6 and wondered why the monkey patching was
not working, therefore documenting this to point this out to future
readers.
* `django.db.{connection, connections, router}` are now hinted -- including `ConnectionHandler` and `ConnectionRouter` classes.
* Several improvements to `BaseDatabaseWrapper` attribute hints.
* In many places, database connections were hinted as `Any`, which I changed to `BaseDatabaseWrapper`.
* In a few places I added additional `SQLCompiler` hints.
* Minor tweaks to nearby code.
* Add type hints for the postgres CursorDebugWrapper, expand the BaseCursorDebugWrapper.
* Fix how Optinal gets applied.
* Fix optional handling further.
* Adjust postgres debugcursorwrapper to look more like the implementation.
* Apply review feedback.
* Use the more generic HttpResponseBase when appriopriate.
* Fix failing test and add new test.
* Remove the other test again, it was the wrong location. Add new tests in the correct location.
Co-authored-by: LanDinh <coding+sourcetree@khaleesi.ninja>
* Update decorators.pyi to match Django 3.1
This commit resembles the state of the file in Django 3.1. Unfortunately, this is not even compatible with Django 3.0 which misses the sync* and async* decorators.
* Update decorators.pyi
* Fixes lint
Co-authored-by: Nikita Sobolev <mail@sobolevn.me>
* Ensure that all registered checks return a list of CheckMessage
This changes missing and Any return types on registered checks to always
return "List[CheckMessage]".
In many cases, check functions were already annotated to return in a more
specific type than CheckMessage (e.g. Error). In these cases, it's assumed
that the existing annotation is correct, and the more specific type is kept.
* Update model_checks.pyi
Co-authored-by: Nikita Sobolev <mail@sobolevn.me>
* Replace models.Model annotations with type variables
* Adds generic type args to generic views
* Adds more tests
* Revert "Adds generic type args to generic views"
This reverts commit 6522f30cdb9027483f46d77167394c84eb7b7f4b.
* Adds Generic support for DetailView and ListView
Co-authored-by: sobolevn <mail@sobolevn.me>
This addresses an obscure crash we're getting when defining a GenericForeignKey
subclass on a model.
Not sure how this slipped through type checking since
`helpers.lookup_class_typeinfo -> Optional[TypeInfo]` while
`.get_private_descriptor_type(type_info: TypeInfo)` so this should be a clear
type violation.
* Add type hints for the postgres CursorDebugWrapper, expand the BaseCursorDebugWrapper.
* Fix how Optinal gets applied.
* Fix optional handling further.
* Adjust postgres debugcursorwrapper to look more like the implementation.
* Apply review feedback.
Co-authored-by: LanDinh <coding+sourcetree@khaleesi.ninja>
* Add URLPattern options to django.url.conf since they were missing.
* Fix some wording in the contribution guide & fix a reference to Django version 3.0, which has since been replaced by 3.1 as new stable version.
* My bad - I was misreading the type hints a bit here. Fix tests.
* We need to specify the List[Union[URLResolver, URLPattern]] upfront, since those don't accept List[URLResolver] as argument.
* Add test to ensure that path() accepts a mix of URLPatterns & URLResolvers.
Co-authored-by: LanDinh <coding+sourcetree@khaleesi.ninja>
Prior to this change, ManyToManyField was declared as being generic in
_ST and _GT, but also used the _T Typevar in its __init__ signature.
This caused mypy to add _T to the variables it was generic in when used
as an alias.
The symptom of this problem was that mypy would show an error with the
message "Type application has too few types (3 expected)" where a
ManyToManyField alias was declared, but adding an extra argument would
fail because the type only takes two arguments.
This change brings the signature of ManyToManyField in line with
ForeignKey and OneToOneField.
* Update static.pyi
Parameters document_root and show_indexes should be marked as Optional since they have a default value.
* Update static.pyi
Correct signature of serve function.
