Remove typing_extensions from run time requirements
Changes
Remove typing_extensions from run time requirements = less dependencies to install for users of aiokafka.
Checklist
- [x] I think the code is well written
- [x] Unit tests for the changes exist
- [ ] Documentation reflects the changes
- [x] Add a new news fragment into the
CHANGESfolder- name it
<issue_id>.<type>(e.g.588.bugfix) - if you don't have an
issue_idchange it to the pr id after creating the PR - ensure type is one of the following:
.feature: Signifying a new feature..bugfix: Signifying a bug fix..doc: Signifying a documentation improvement..removal: Signifying a deprecation or removal of public API..misc: A ticket has been closed, but it is not of interest to users.
- Make sure to use full sentences with correct case and punctuation, for example:
Fix issue with non-ascii contents in doctest text files.
- name it
In general, it's better to avoid using if TYPE_CHECKING guards. They can be contagious (forcing library users to also use such guards) and may break code that evaluates annotations at run time (such as pydantic). However, starting with Python 3.12 typing_extensions is no longer necessary, and Python 3.11 has retired (in security-fix-only mode) for over a year. Therefore, it would be ideal to remove this requirement entirely for modern Python versions instead.
@ods Thanks for the review. My thinking so far was:
- the
typing_extensionspackage is not about specific Python versions. It brings new type system features from the latest stable Python version to older Python versions, as they claim it here. So the package itself won't go away if code bases make use of newly added features from it. - aiokfaka has ruff + the pyupgrade rule activated (see), which does import replacements like
from typing_extensions import Concatenate->from typing import Concatenate. So the usage of types from thetyping_extensionspackage are gradually phased out depending on therequires-pythondefinition specified in the pyproject.toml. Soif TYPE_CHECKINGwill cease existing in case everybody refrains from importing even newer type features from a newertyping_extensionspackage versions. if TYPE_CHECKINGfor me remains important for expensive imports for code that works with delayed imports for fast startups, to break circular imports and to not depend on packages with type definitions that are irrelevant during runtime as not evaluated.- regarding pydantic: My understanding is that you can only be sure via model_rebuild() that really all types are available at runtime ... types can be missing due to multiple reasons like
if TYPE_CHECKINGguarded imports but also "string-based type annotations". This code base does not use pydantic, so we do not have to make sure to run model_rebuild once against all models in unit tests to check that.
tl;dr so even if we introduce if TYPE_CHECKING, pyupgrade will phase it out in future when it becomes unneeded due newer min python version. And I personally see reasons to not depend on packages with type definitions that are irrelevant during runtime as not evaluated (there also is no pydantic in this codebase).