Skip to content

gh-117865: Defer several imports in inspect.py #119526

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

AlexWaygood
Copy link
Member

@AlexWaygood AlexWaygood commented May 24, 2024

Following 153b3f7, it is suddenly much more trivial to make the import of ast lazy in inspect.py. Once that's done, it also becomes worthwhile to make other imports lazy as well

@AlexWaygood
Copy link
Member Author

I'm about to board a flight, but I think this cuts nearly 50% off the import time for inspect

@AlexWaygood
Copy link
Member Author

(But this is possibly a redundant optimisation if it turns out that inspect needs to depend on ast more heavily due to PEP 649 anyway? Not sure)

@AlexWaygood
Copy link
Member Author

I'll keep this on the back burner until it's decided where the new PEP-649 functions will go, and which modules they'll depend on

@AlexWaygood AlexWaygood added DO-NOT-MERGE performance Performance or resource usage labels May 29, 2024
Copy link
Member

@JelleZijlstra JelleZijlstra left a comment

Choose a reason for hiding this comment

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

(This showed up in my list of review requests, so I want to clear it out even if it's a draft.)

I think we can apply the changes that don't affect ast. My current implementation of the PEP 649 functionality relies very heavily on ast, so it's likely we won't be able to defer that import.

@AlexWaygood
Copy link
Member Author

I think we can apply the changes that don't affect ast.

Right -- but ast itself imports a bunch of stuff, so I'm not sure how much deferring the other imports helps if we can't defer the ast import. It might just make the code uglier for no apparent gain. I'll play around a bit when I get a chance; maybe now we've deferred the re import in ast things might have changed...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DO-NOT-MERGE performance Performance or resource usage
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants