aiokafka icon indicating copy to clipboard operation
aiokafka copied to clipboard

Remove typing_extensions from run time requirements

Open dbast opened this issue 7 months ago • 2 comments

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 CHANGES folder
    • name it <issue_id>.<type> (e.g. 588.bugfix)
    • if you don't have an issue_id change 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.

dbast avatar May 16 '25 09:05 dbast

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 avatar May 17 '25 05:05 ods

@ods Thanks for the review. My thinking so far was:

  • the typing_extensions package 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 the typing_extensions package are gradually phased out depending on the requires-python definition specified in the pyproject.toml. So if TYPE_CHECKING will cease existing in case everybody refrains from importing even newer type features from a newer typing_extensions package versions.
  • if TYPE_CHECKING for 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_CHECKING guarded 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).

dbast avatar May 17 '25 07:05 dbast