Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 810 – Explicit lazy imports

peps.python.org

Post reply on HN
Print view View original

121–130 of 247 posts

Re: PEP 810 – Explicit lazy imports

#121

Post by stefan_ »

zahlman wrote: post #112
aftbit wrote: post #94

Earlier quoted context omitted.

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://…

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

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

Re: PEP 810 – Explicit lazy imports

#122

Post by nilslindemann »

This is the wrong syntax, comparable to how "u" strings were the wrong syntax and "b" strings are the right syntax.

They make that, what should be the default, a special case. Soon, every new code will use "lazy". The long term effect of such changes is a verbose language syntax.

They should have had a period where one, if they want lazy imports, has to do "from __future__ import lazy_import". After that period, lazy imports become the default. For old-style immediate imports, introduce a syntax: "import now foo" and "from foo import now bar".

All which authors of old code would have to do is run a provided fix script in the root directory of their code.

Re: PEP 810 – Explicit lazy imports

#123

Post by nilslindemann »

nilslindemann wrote: post #122

This is the wrong syntax, comparable to how "u" strings were the wrong syntax and "b" strings are the right syntax. They make that, what should be the default, a special case. Soon, every new code will use "lazy". The long term effect of such changes is a verbose language syntax. They should have had a period where one, if they want lazy imports, has to do "from __future__ import lazy_import". After that period, lazy…

In short, grandiose change, wrong syntax.

Re: PEP 810 – Explicit lazy imports

#125

Post by dataangel »

forrestthewoods wrote: post #22

I don’t want lazy imports. That’s just makes performance shitty later and harder to debug. It’s a hacky workaround. What I want is for imports to not suck and be slow. I’ve had projects where it was faster to compile and run C++ than launch and start a Python CLI. It’s so bad.

imports run arbitrary Python code, making them faster is the same as making every other language feature faster

Re: PEP 810 – Explicit lazy imports

#126

Post by johnfn »

mekoka wrote: post #119
comex wrote: post #67

I don't hate it but I don't love it. It sounds like everyone will start writing `lazy` before essentially every single import, with rare exceptions where eager importing is actually needed. That makes Python code visually noisier. And with no plan to ever change the default, the noise will stay forever. I would have preferred a system where modules opt in to being lazy-loaded, with no extra syntax on the import side.…

If everyone starts favoring lazy imports with not much fuss then it means that lazy should have been the default behavior and eager is the keyword we're missing. This isn't the first time Python revisits this paradigm. Many constructs that used to eagerly produce lists in v2 were turned into generators in v3 with next to no problems.

Yes, there were totally no problems in the transition from 2 to 3 :)

Re: PEP 810 – Explicit lazy imports

#127

Post by gigatexal »

dheera wrote: post #45
charliermarsh wrote: post #21

Lazy imports have been proposed before, and were rejected most recently back in 2022: https://discuss.python.org/t/pep-690-lazy-imports-again/1966... . If I recall correctly, lazy imports are a feature supported in Cinder, Meta's version of CPython, and the PEP was driven by folks that worked on Cinder. Last time, a lot of the discussion centered around questions like: Should this be opt-in or opt-out? At what level?…

Oof. I wish they could support version imports import torch==2.6.0+cu124 import numpy>=1.2.6 and support having multiple simultaneous versions of any Python library installed. End this conda/virtualenv/docker/bazel/[pick your poison] mess

Really what is the headache with virtual environments? They’ve been solved. Use UV or python’s built in venv creator and you’re good to go.

uv venv —seed —python=3.12 && source .venv/bin/activate && pip3 install requests && …

Re: PEP 810 – Explicit lazy imports

#128

Post by hiq »

aftbit wrote: post #33

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.

This sounds like something that should be covered by tests?

Re: PEP 810 – Explicit lazy imports

#129

Post by 0cf8612b2e1e »

driggs wrote: post #82
zahlman wrote: post #60

Earlier quoted context omitted.

It's been explained many times before why this is not possible: the library doesn't actually have a version number. The distribution of source code on PyPI has a version number, but the name of this is not connected to the name of any module or package you import in the source code. The distribution can validly define zero or more modules (packages are a subset of modules, represented using the same type in the Pytho…

> It's been explained many times before why this is not possible: the library doesn't actually have a version number. Not possible ? Come on. Almost everyone already uses one of a small handfull of conventional ways to specify it, eg `__version__` attribute. It's long overdue that this be standardized so library versions can reliably be introspected at runtime. Allowing multiple versions to be installed side-by-side…

I believe the charitable interpretation is that it is not possible without breaking an enormous amount of legacy code. Which does feel close enough to “not possible”.

Some situations could be improved by allowing multiple library versions, but this would introduce new headaches elsewhere. I certainly do not want my program to have N copies of numpy, PyTorch, etc because some intermediate library claims to have just-so dependency tree.

Re: PEP 810 – Explicit lazy imports

#130

Post by oivey »

dheera wrote: post #45
charliermarsh wrote: post #21

Lazy imports have been proposed before, and were rejected most recently back in 2022: https://discuss.python.org/t/pep-690-lazy-imports-again/1966... . If I recall correctly, lazy imports are a feature supported in Cinder, Meta's version of CPython, and the PEP was driven by folks that worked on Cinder. Last time, a lot of the discussion centered around questions like: Should this be opt-in or opt-out? At what level?…

Oof. I wish they could support version imports import torch==2.6.0+cu124 import numpy>=1.2.6 and support having multiple simultaneous versions of any Python library installed. End this conda/virtualenv/docker/bazel/[pick your poison] mess

Oof. This feature request has nothing to do with lazy imports. It’s also solved far more cleanly with inline script metadata.
Post reply on HN