Comment by aftbit - Hacker Neue

aftbit Oct 3, 2025 parent

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.

zahlman Oct 3, 2025

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.

aftbit OP Oct 3, 2025

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.

https://peps.python.org/pep-0810/#global-lazy-imports-contro...

zahlman Oct 3, 2025

It saddens me to think that the use case of "python CLI tools" is thought of as anything like "very specific" or "narrow".

aftbit OP Oct 6, 2025

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.

zahlman Oct 6, 2025

> 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).

stefan_ Oct 3, 2025

These tools already have a million ways to avoid this slowdown. Is it so much to ask their authors to care?

ashu1461 Oct 3, 2025

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.

bityard Oct 3, 2025

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?

maest Oct 3, 2025

Who is "we"?

aftbit OP Oct 3, 2025

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".

hiq Oct 3, 2025

This sounds like something that should be covered by tests?

This item has no comments currently.

Preferences

Keyboard Shortcuts

Story Lists

Navigation

Miscellaneous