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

71–80 of 247 posts

Re: PEP 810 – Explicit lazy imports

#71

Post by BugsJustFindMe »

zahlman wrote: post #60
dheera wrote: post #45

Earlier quoted context omitted.

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

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

You're making the common mistake of conflating how things currently work with how things could work if the responsible group agrees to change how things work. Something being the way it is right now is not the same as something else being "not possible".

Re: PEP 810 – Explicit lazy imports

#72

Post by BiteCode_dev »

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

We heard that about types, the walrus, asyncio, dataclasses and so much more. But it didn't happen, if people don't need something (and many don't know it exists or what it does), it's unlikely they use it.

In fact, half of the community basically uses only a modernized set of python 2.4 features and that's one of the beauties of the language. You don't need a lot to be productive, and if you want more, you can optionally reach for it.

It has worked very well for the last 2 decades and it will likely work again.

Re: PEP 810 – Explicit lazy imports

#73

Post by zahlman »

eesmith wrote: post #17
sedatk wrote: post #3

I wonder how much things would break if all imports were lazy by default.

All my code which uses import probing would fail, such as fallbacks: try: import module except ImportError: import slow_module as module Conditional support testing would also break, like having tests which only run if module2 is available: try: import module2 except ImportError: def if_has_module2(f): return unittest.skip("module2 not available")(f) else: def if_has_module2(f): return f @if_has_module2 class TestMod…

With the LazyLoader technique I described at https://news.ycombinator.com/item?id=45467489 , there is no problem:

  >>> import nonexistent_module
  Traceback (most recent call last):
    File "", line 1, in 
      import nonexistent_module
    File "", line 1360, in _find_and_load
    File "", line 1322, in _find_and_load_unlocked
    File "", line 1262, in _find_spec
    File "", line 8, in find_spec
      base.loader = LazyLoader(base.loader)
                               ^^^^^^^^^^^
  AttributeError: 'NoneType' object has no attribute 'loader'
The implementation should probably convert that exception back to ImportError for you, but the point is that the absence of an implementation can still be detected eagerly while the actual loading occurs lazily.

Re: PEP 810 – Explicit lazy imports

#74

Post by BiteCode_dev »

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?…

Especially since it is opt in, with various level of granularity, and a global off switch. Very well constructed spec given the constraints.

Re: PEP 810 – Explicit lazy imports

#75

Post by Spivak »

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

I don't think this makes sense to be on the module side, the caller is the one with the information as to whether the module can or needs to be lazily loaded. There's nothing really for the module being imported to decide, every module can be lazily loaded. Even if it has side effects the caller may want to defer those as well.

Re: PEP 810 – Explicit lazy imports

#76

Post by lenkite »

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

Wish pyproject.toml was enhanced to specify lazy loading via regexs.

Re: PEP 810 – Explicit lazy imports

#77

Post by johannes1234321 »

zahlman wrote: post #60
dheera wrote: post #45

Earlier quoted context omitted.

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

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…

If vereioned imports were added to the language versioned library support obviously would have to become part of the language as well.

However it isn't trivial. First problem coming to my mind:

module a importing first somelib>=1.2.0 and then b and b then requiring somelib>1.2.1 and both being available, will it be the same or will I have a mess from combining?

Re: PEP 810 – Explicit lazy imports

#78

Post by zahlman »

the__alchemist wrote: post #13

Does this fix the circular imports problem that comes up if you don't structural your programs in a hierarchical way?

Even with eager importing there is only a "circular import problem" if you try to import names `from` the modules — as I pointed out a few days ago (https://news.ycombinator.com/item?id=45400783).

Re: PEP 810 – Explicit lazy imports

#79

Post by BiteCode_dev »

f311a wrote: post #26

I don't like the idea of introducing a new keyword. We need a backward compatible solution. I feel like Python needs some kind of universal annotation syntax such as in go (comments) or in Rust (macros). New keyword means all parsers, lsps, editors should be updated. I’m pretty sure there will be new keywords in Python in the future that only solve one thing.

They thought about backward compatibility, and offer an alternative syntax that use no keyword for library that want to activate it yet stay compact with old version. It's already in the spec.
Post reply on HN