Closed mthuurne closed 6 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 98.94%. Comparing base (
4c9d6ee
) to head (c75e54a
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
In the summary, I wrote:
As a lot of other libraries are using
typing_extensions
already, I'm not sure if it avoiding the dependency indjango-model-utils
would actually make a difference in any real-world application.
In our own Django application, it turns out only scipy
depends on typing_extensions
, and it has it as an optional dev dependency rather than a runtime dependency. So perhaps I overestimated how many libraries are using it.
Thans for your throughout description of this PR.
Is the typing_extensions
thing something we can solve in another way?
Is the
typing_extensions
thing something we can solve in another way?
I used it in several places in earlier versions of the annotations, but in the latest version there are no uses left. I'll drop it from this PR and we can see whether or not to add it later if/when there is a concrete use case to discuss.
This is a first step in adding type annotations. See #558 for discussion.
Some things to pay attention to during review:
I'm using
from __future__ import annotations
to force postponed evaluation of annotations. This has several advantages:dict[str, str]
orint | None
to be used in Python versions where the interpreter doesn't support that syntax yetQuerySet
in Django 3.2, whereQuerySet
does not yet inherit fromtyping.Generic
I added
typing_extensions
as a runtime dependency. This makes it possible to use both runtime and static features from newer versions of Python in older versions as well. In particular,typing.Self
simplifies a lot of annotations, but was only added to the standard library in Python 3.11.It is possible to only use static features of
typing_extensions
and put the import within aif TYPE_CHECKING:
guard. It makes maintenance a bit more cumbersome, but it would eliminate the runtime dependency. As a lot of other libraries are usingtyping_extensions
already, I'm not sure if it avoiding the dependency indjango-model-utils
would actually make a difference in any real-world application. But if you want me to make that change, let me know.I've used Python 3.8 in the tox configuration to run mypy, because that is the one that also runs flake8 and isort. I'm not sure that's a good reason though. Another option would be to use Python 3.12, as that is the fastest. Note that mypy's results do not depend on the Python version it runs under: it always has access to all typing features it supports.
The type checking of the unit tests requires all imported libraries to exist, which is why I added
time_machine
as a dependency of the mypy env in tox. If we want to avoid that duplication, maybe it would make sense to create arequirements-testlib.txt
or add atestlib
extra tosetup.py
.It would also be possible to move
time_machine
intorequirements-test.txt
, but installing the test tools and runtime dependencies likepsycopg2-binary
isn't necessary for mypy to work and I wanted to avoid slowing down CI.