Avoid import-time dependency on typing in common cases #329
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
Part of #326.
Overview
typingas a import-time dependency can be avoided for most of this library's use cases through a combination of the following:typing.functools.singledispatchtypingat import time, so that importing them is opt-in.importlib_resources.abc.Traversable__getattr__.This way, when importing just the base or functional API (
files(),as_file(),open_binary, etc.), which I imagine is a very common use case, users don't also importtypingimmediately as a side-effect. This will improve the import time ofimportlib_resourcesfor such common cases by at least 10%, possibly more, while still having the type annotations be valid and resolve to the correct symbols when introspected/evaluated.This PR's intended viewing is commit by commit, in order.
Notes
I'm guessing this one will be a bit more controversial than the other PRs due to refactoring away usage of
functools.singledispatch, but if we want to usetypingwithout incurring its import cost on multiple Python versions, I think it's easiest to just avoidsingledispatchaltogether inimportlib_resources._common.singledispatchusage is also a potential blocker for possible future improvements, e.g. lazily importingpathlib.Path.That being said, I'll try to see if there's a way to use
singledispatchfor the moment without it unconditionally importingtyping. Doing so would rely on implementation details and thus be fragile at best, so I'm not a fan of it.