(Replying as an individual developer – you don’t need to convince me, in the SC I try to read community consensus rather than assert my own views.)
I would support that.
Overall, I think we should make it easier for libraries to use lazy imports themselves, à la SciPy or Mercurial.
The current proposal is made for “applications” with tightly controlled set of dependencies. Those are relatively rare in open-source code, and closed-source ones don’t have a good way to report bugs that only appear in a specific setup back to the libraries they’re using. And the libraries can’t test things themselves very well.
The PEP explicitly rejects explicit syntax as fragile “shallow” laziness, but doesn’t really give examples or evidence, just “we tried, it didn’t work”, so it’s difficult to say how well it generalizes outside their use cases. (Apologies for the very rough paraphrasing – it was said much more nicely of course.)
I don’t think lazy imports can be solved without either buy-in from the ecosystem at large (i.e. putting pressure on libraries), or “applications” spending effort to keep -L working. I worry that the people who’d turn on -L also can patch their CPython and their dependencies – at least for a few releases.
Porting to explicit lazy imports, library by library, would take time and effort, but might eventually give better results ecosystem-wide.
There might be a parallel with async – gevent’s patching worked immediately for an application, but was more fragile; async took/takes effort but is ultimately a better solution.
With explicit lazy imports, we could get away with rougher side effects, avoiding too much magic. Dicts could focus on being containers. Code that needs too much introspection or dynamic features simply wouldn’t opt in.
Why not both? Syntax as the preferred future way, and a function for older versions and dynamic imports. (Granted, dynamic imports wouldn’t be too useful outside testing the feature itself.)