Typed-lazyimport

Latest version: v0.3.1

Safety actively analyzes 688433 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 2

0.3.1

Fix:
* A bug where assignment of a variable to a library not yet imported would have failed. Now triggers the library to be imported first in such cases, ensuring it's present before the assignment is attempted (event sequencing type of bug).

_Very unlikely to have affected anyone though, as I can't think of a single reason why the first thing one wants to do after importing a library is to assign a variable to it. But it's possible to do and thus the fix._

0.3.0

Adds:
* `Import` primitive that creates a transparent lazy-import proxy

This primitive already existed since the very first version of the package, but it was never exposed.
The reason it is exposed now is because it makes sense for uses where type hints are not important, such as for small one-off / quick-and-dirty scripts or CLI programs. In such cases type hinting may be overkill as one can correctly reason about the code when it's short enough.

The readme has been updated with an example showing its use.

0.2.0

New minor version because the change is externally observable.

Change:
* The lazy load proxy now stays in place, but delegates all attribute access (get/set) to the managed library. This gets rid of a corner-case that was related to variable binding.

Previously the libraries referenced had different behavior depending on how and when they were bound to a variable, while in the new version the binding does not matter; the behavior is identical.

Previously:
python
from lazyimport import Libs
torch = Libs.torch

assert torch is Libs.torch
torch.__version__

assert torch is not Libs.torch this is a problem
assert vars(torch) != vars(Libs.torch) this is an even bigger problem


This difference in binding behavior meant that when using a short variable name as an alias (as is the intended use case) that alias variable was directly referencing the proxy. However, the implementation was a bit too clever in that it also swapped the proxy for the real module (library) on the "Libs" (container) object. The intent was to make the container hold the native modules without any proxy involved after a module had been imported (loaded). Unfortunately since there is no way in python to change the binding of all variables referencing a given object, the above discrepancy in behavior resulted.

New behavior:
python
from lazyimport import Libs
torch = Libs.torch

assert torch is Libs.torch
torch.__version__

assert torch is Libs.torch fixed
assert vars(torch) == vars(Libs.torch) fixed


The new version does away with the "cleverness" and instead sticks to letting the proxy be in place regardless of whether the module has been imported or not. To ensure the proxy looks and behaves exactly like the actual module, all attribute access and setting is being forwarded to the underlying library, which means, aside from a type check, that the proxy looks and behaves exactly like the underlying module. It therefore also passes the `isinstance(proxy, ModuleType)` check.

To ensure having the proxy in place is not expensive, it only incurs two extra python calls (two attribute lookups). Since referencing top level modules is typically not on the critical path, that overhead should be negligible.

0.1.5

Adds:
* Set of libraries supported for immediate lazy import use.

0.1.4

Fixes:
* An invalid example in the readme.

0.1.3

Adds:
* Documentation for the Lib function
* Unit test to show the corresponding use from the documentation.

Page 1 of 2

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.