-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Make is_sub_path faster #17962
Make is_sub_path faster #17962
Conversation
See python#17948 Haven't run the benchmark yet, but profile indicates that this could save 0.5s on both incremental and non-incremental builds in environments with long search path
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This reverts commit a9602be.
This comment has been minimized.
This comment has been minimized.
"""Given two paths, return if path is a sub-path of dir.""" | ||
if not dir.endswith(os.sep): | ||
dir += os.sep | ||
return path.startswith(dir) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this will work reliably on Windows, where path separators can be /
or \
, and these are largely equivalent? Should we normalize separators on Windows, or can we assume everything is normalized here? I noticed that you added a call to os.path.normcase
, so maybe this is already ok.
Maybe update docstring to mention Windows-specific issues, and case insensitivity issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documented the shortcomings of the faster function + invariants we require in modulefinder. Also renamed the function so it sounds a little scarier
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
See #17948 - 1.01x faster on clean - 1.06x faster on long - 1.04x faster on openai - 1.26x faster on openai incremental
See #17948