Closed dschult closed 1 year ago
Merging #57 (42ac558) into main (a6188ac) will increase coverage by
3.42%
. The diff coverage is100.00%
.
:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@ Coverage Diff @@
## main #57 +/- ##
==========================================
+ Coverage 90.53% 93.95% +3.42%
==========================================
Files 4 4
Lines 169 182 +13
==========================================
+ Hits 153 171 +18
+ Misses 16 11 -5
Impacted Files | Coverage Δ | |
---|---|---|
lazy_loader/__init__.py | 91.86% <100.00%> (+6.49%) |
:arrow_up: |
lazy_loader/tests/test_lazy_loader.py | 96.73% <100.00%> (+0.35%) |
:arrow_up: |
LGTM. We can always deprecate (and later remove) load
in a subsequent PR if we want.
Thanks you @dschult. It's also worth referencing https://github.com/scientific-python/lazy_loader/issues/55.
The
importlib.find_spec
tool automatically (and eagerly) imports packages when subpackages are asked to be found. The olderfind_loader
did not do that, but it is deprecated and will be removed in python v3.12. While it might be possible to make theload
feature work using manually buildModuleSpec
s, the payoff is unlikely to be worth the convoluted errors obtained when something goes awry. It would/will be much more effective for people to encourage the package toattach
the subpackages so they can be lazily loaded.That said, packages can still be lazily
load
ed. And even subpackages can be lazilyload
ed though this causes the package to be eagerly imported. So there might be some use for thisload
function. This potential benefit might be enough reason to keep the function in this library. But I can also see that removing the function altogether would be reasonable too.With that in mind, this PR changes the function to raise a RuntimeWarning when the input is a subpackage (has "." in the name of the package). It also changes the doc_strings to discourage the use of
lazy.load(sub.package)
. And it adds a test to check for the warning, and to verify that the return value ofload
with subpackage input continues to provide an eagerly imported package with a lazily loaded subpackage.I think this is better than leaving
load
unchanged -- some of the docs even suggested using it for subpackages.But, is this better than removing
load
?