I find that the implemented module existence checks were unnecessary or unnecessarily complicated.
FYI - In the first commit message, I wrote:
"Original implementation loops over a relatively large dict. Yes, it's O(1), but that O(1) can still be a relatively large operation."
To clarify, here I am referring to the fact that a dict (of all available packages) was being created (O(n)), and subsequently the dict was checked for the name of the target package as a key entry (O(1)). This function was being called (with each call being O(1)) multiple times throughout the package. While these O(1) operations are small, they can add up and contribute to the (perceived) slow imports.
At times (e.g., L46-53 in https://github.com/sandialabs/pyapprox/commit/93394fbad1b5673b16948e00fa27812daed2411a ) it is simpler and more direct to simply attempt to import the target package. The advantage is that it incurs essentially no runtime cost if successful, in contrast to the original approach. The code is more pythonic and, at least to me, cleaner and easier to understand as well.
I find that the implemented module existence checks were unnecessary or unnecessarily complicated.
FYI - In the first commit message, I wrote: "Original implementation loops over a relatively large dict. Yes, it's O(1), but that O(1) can still be a relatively large operation."
To clarify, here I am referring to the fact that a
dict(of all available packages) was being created (O(n)), and subsequently thedictwas checked for the name of the target package as a key entry (O(1)). This function was being called (with each call beingO(1)) multiple times throughout the package. While theseO(1)operations are small, they can add up and contribute to the (perceived) slow imports.At times (e.g., L46-53 in https://github.com/sandialabs/pyapprox/commit/93394fbad1b5673b16948e00fa27812daed2411a ) it is simpler and more direct to simply attempt to import the target package. The advantage is that it incurs essentially no runtime cost if successful, in contrast to the original approach. The code is more pythonic and, at least to me, cleaner and easier to understand as well.