3 ms·

We tend to prefer explicit top-level imports specifically because they reveal dependency problems as soon as the program starts, rather than potentially hours o

by aftbit 1y ago

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.

maest 1y ago
Who is "we"?
- aftbit 1y ago
  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".
bityard 1y ago
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?
ashu1461 1y ago
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.
zahlman 1y ago
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 1y ago
  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-control https://peps.python.org/pep-0810/#global-lazy-imports-contro...
  - zahlman 1y ago
    It saddens me to think that the use case of "python CLI tools" is thought of as anything like "very specific" or "narrow".
    - stefan_ 1y ago
      These tools already have a million ways to avoid this slowdown. Is it so much to ask their authors to care?
    - aftbit 1y ago
      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 1y ago
        > 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 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).
hiq 1y ago
This sounds like something that should be covered by tests?

by aftbit 1y ago

maest 1y ago

Who is "we"?

aftbit 1y ago
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".

bityard 1y ago

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?

ashu1461 1y ago

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.

zahlman 1y ago

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 1y ago
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-control https://peps.python.org/pep-0810/#global-lazy-imports-contro...
- zahlman 1y ago
  It saddens me to think that the use case of "python CLI tools" is thought of as anything like "very specific" or "narrow".
  - stefan_ 1y ago
    These tools already have a million ways to avoid this slowdown. Is it so much to ask their authors to care?
  - aftbit 1y ago
    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 1y ago
      > 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 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).

hiq 1y ago

This sounds like something that should be covered by tests?