Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce import time by removing string and tomli._types imports #249

Merged
merged 1 commit into from
Jan 9, 2025

Conversation

hukkin
Copy link
Owner

@hukkin hukkin commented Jan 9, 2025

No description provided.

Copy link

codecov bot commented Jan 9, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (42a570d) to head (764c9ca).
Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##            master      #249   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            4         4           
  Lines          529       525    -4     
  Branches        97        97           
=========================================
- Hits           529       525    -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@hauntsaninja hauntsaninja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

Note that hiding the Iterable import doesn't do anything, typing imports collections.abc. If you want to get rid of that you'll need to do the TYPE_CHECKING = False trick

@hukkin
Copy link
Owner Author

hukkin commented Jan 9, 2025

Thanks for the review!

I think similarly the lazy import warnings does nothing here as there's some other module that is importing warnings. I made those changes while experimenting, and thought it may be good to leave them in, as they do no harm, and can in theory have an effect in the future if the imported libraries change.

Unfortunately, since we use typing.NamedTuple (used at runtime) I don't think even the TYPE_CHECKING = False trick will spare us from the need to import typing (and subsequent collections.abc).

I was wondering if the discussion about making TYPE_CHECKING a builtin deserves a revisit. Python 3.14 will make typing module also import annotationlib, so a little more import overhead that is hard to avoid in small (type annotated) CLI tools.

@hauntsaninja
Copy link
Collaborator

hauntsaninja commented Jan 9, 2025

CPython has been moving towards deferring imports of warnings, so hopefully that one will pay off at some point.

Yeah, could be worth revisiting. If you want something now, in practice, type checkers will recognise if you just define TYPE_CHECKING yourself:

TYPE_CHECKING = False
if TYPE_CHECKING:
    from typing import List

def foo(x: List[int]):
    reveal_type(x)

@hukkin hukkin merged commit 4188188 into master Jan 9, 2025
36 checks passed
@hukkin hukkin deleted the importtime branch January 9, 2025 09:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants