I'm not working on a PR for this right now. As @picnixz said though, there's no clear answer on what to do though.

The documentation has been changed since I made this issue and now states:

When a lazily imported module is accessed for the first time, its name is typically removed from this set.

So technically it now matches the documentation but I don't think this is good behaviour that we should have.

cc @DinoV @pablogsal for what they think we should do here (and whether we should do anything as well)

I see two ways to go here:

1. Immediately return cached sys.modules entry in lazy import x
2. Clean up sys.lazy_modules in cached paths (regular import or cached lazy import x + cached lazy from x import X)

For (1), plain lazy import x currently creates a proxy and adds x to sys.lazy_modules, even if the module is already cached. Accessing the proxy later calls the ordinary import machinery, whose cache lookup returns the existing module.

lazy from x import X already has an eager cache fast path, i.e. if x is cached in sys.modules and that dictionary contains X, it returns that attribute directly instead of creating an attribute proxy.

I prefer we check the cache in lazy import x and return early too, since lazy from x import X already does that.

For (2), cleanup currently happens when a module is loaded (not returned from cache). _find_and_load_unlocked() calls _imp._set_lazy_attributes() after loading, and that function discards the loaded module's name from sys.lazy_modules.

lazy from registers the parent module name and the qualified imported name, such as x.X before taking its eager attribute fast path, so consequently:

• If resolving X loads x, cleanup removes x, but an ordinary attribute entry x.X remains.
• If X is a submodule actually loaded as x.X, its module-loading path removes x.X.
• If x and its attribute X are already available, the eager fast path returns X without removing either entry.

I believe we can fix both (1) and (2).

Judging by the fact that we already do cache lazy from x import X, I think it's correct to do the same in the simpler case, lazy import x. We should definitely clean up sys.lazy_modules in cached paths, so there is something to do regardless. I'll start making a patch, we can iterate. EAFP.

Hi, I'm working with @pablogsal to tie up loose ends around Lazy Imports ahead of the 3.15 final cut.
In the sake of time, I put together a PR to address both parts (1) and (2) of the issue. If you already have a change that you prefer--no hard feelings! That works too.

@brittanyrey No worries at all, I hope I helped here. I can help reviewing, ping me anytime. Thanks for taking over and working on this.