We tend to prefer explicit top-level imports specifically because they reveal dependency problems as soon as the program starts, rather than potentially hours or days later when a specific code path is executed.
As a counterpoint, having all the imports automatically deferred would instantly dramatically speed up pip for short tasks.
$ time pip install --disable-pip-version-check
ERROR: You must give at least one requirement to install (see "pip help install")
real 0m0.399s
user 0m0.360s
sys 0m0.041s
Almost all of this time is spent importing (and later unloading) ultimately useless vendored code. From my testing (hacking the wrapper script to output some diagnostics), literally about 500 modules get imported in total (on top of the baseline for a default Python process), including almost a hundred modules related to Requests and its dependencies, even though no web request was necessary for this command.
I think this makes a ton of sense in the very specific narrow use case of python CLI tools. For a web app or other long-lived process, startup time is typically not of extreme concern, and having more simplicity and legibility to the import process seems better.
That's not to say this PEP should not be accepted. One could always apply a no-lazy-imports style rule or disable it via global lazy import control.
There are tons of great CLI tools written in Python, but I would wager that the vast majority of Python code, no matter how you count it, isn't in a CLI tool. Certainly it's a worthy goal to speed them up especially given how frequently things like `pip` are run both by humans who have better things to do than wait on computers, and by automation which does things at giant scale. But most Python project and programmers who are not making CLI tools or other startup-latency sensitive stuff may be better served by the old default import style.
> But most Python project and programmers who are not making CLI tools or other startup-latency sensitive stuff may be better served by the old default import style.
That may well be the case, and Python's development processes would definitely tend to assume the same. That has a lot to do with why PEP 690 was rejected, and why this proposal is opt-in even though many people are concerned that a lot of projects will "opt in everywhere" and create a lot of noise.
Believe it or not, the process is actually very conservative. People complaining about the "churn" caused by deprecations and removals seem not to have any concept of how few suggestions actually get implemented, and how many are rejected (including ones that perennially occur to many new users). A browse through "ideas" forum where new pre-PEP ideas are commonly pitched (https://discuss.python.org/c/ideas/6) gives one the impression of a leisurely stroll through a graveyard.
And many people (including myself) can tell you that you'll often be put through a run-around: if your idea is good and can be implemented, then surely it falls on you to make and publicize (!) a third-party package, to prove the demand and the community support for your specific implementation; but if you somehow get there, now it's trivial for people to install support, so it doesn't need to be in the standard library (cf. Requests).
Right, Not sure why but a lot of code which claude generates also comes with local dependencies vs globally declared import statements. Don't promote that pattern because
- It reduces visibility into a module’s dependencies.
- It increases the risk of introducing circular dependencies later on.
I haven't fully digested the PEP but perhaps there would be a command-line flag or external tool for dependency validation, a bit like how there are external tools for type annotations?
My current team at my current company (see bio if you're really interested), though I should say I'm not authorized to speak on behalf of my employer, so I should really say something more like "I".
