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

41–50 of 247 posts

Re: PEP 810 – Explicit lazy imports

#41

Post by vvpan »

sigmoid10 wrote: post #35
Alir3z4 wrote: post #31

Earlier quoted context omitted.

Me neither. Introducing new keyword has become a recent thing in Python. Seems Python has a deep scare since Python2 to Python3 time and is scared to do anything that causes such drama again. For me, the worst of all is "async". If 2to3 didn't cause much division, the async definitely divided Python libraries in 2. Sync and Async. Maybe if they want backward compatible solution, this can be done by some compile or ru…

Async or not in modules is a huge pain in the ass for web-dev, but thankfully a lot of Python still isn't web dev. As a Data Scientist you can live your life peacefully without ever worrying about this. But I can see why web devs like it, even though personally I really don't want to see anymore Javascript sneaking inty my Python. Especially when there is already support for IO bound concurrency elsewhere in the lang…

I'm relatively new to Python - how does one do concurrent IO without async/await?

My main complaint, though, about Python async is - because it is opt-in I never know if I forgot a sync IO call somewhere that will block my worker. JS makes everything async by default and there is effectively no chance of blocking.

Re: PEP 810 – Explicit lazy imports

#43

Post by jmward01 »

This is needed, but I don't like new keywords. What I would love, for many reasons, is if we could decorate statements. Then things like:

import expensive_module

could be:

@lazy

import expensive_module

or you could do:

@retry(3)

x = failure_prone_call(y)

lazy is needed, but maybe there is a more basic change that could give more power with more organic syntax, and not create a new keyword that is special purpose (and extending an already special purpose keyword)

Re: PEP 810 – Explicit lazy imports

#45

Post by dheera »

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

Re: PEP 810 – Explicit lazy imports

#46

Post by jmward01 »

jmward01 wrote: post #43

This is needed, but I don't like new keywords. What I would love, for many reasons, is if we could decorate statements. Then things like: import expensive_module could be: @lazy import expensive_module or you could do: @retry(3) x = failure_prone_call(y) lazy is needed, but maybe there is a more basic change that could give more power with more organic syntax, and not create a new keyword that is special purpose (and…

As a side note, It would be great to have a 'preview' for HN comments. I updated the above because I forgot to add line breaks. Sigh. I bet 'preview' would stop a lot of not well thought out comments too.

Re: PEP 810 – Explicit lazy imports

#47

Post by progval »

jmward01 wrote: post #43

This is needed, but I don't like new keywords. What I would love, for many reasons, is if we could decorate statements. Then things like: import expensive_module could be: @lazy import expensive_module or you could do: @retry(3) x = failure_prone_call(y) lazy is needed, but maybe there is a more basic change that could give more power with more organic syntax, and not create a new keyword that is special purpose (and…

For what it's worth, you can already do: x = retry(3)(failure_prone_call)(y)

Re: PEP 810 – Explicit lazy imports

#48

Post by bkettle »

ashu1461 wrote: post #37
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.

Not sure if this can be made backward compatible. Right now all the imports are getting resolved at runtime example in a code like below from file1 import function1 When you write this, the entire file1 module is executed right away, which may trigger side effects. If lazy imports suddenly defer execution, those side effects won’t run until much later (or not at all, if the code path isn’t hit). That shift in timing…

I think they mean backwards-compatible syntax-wise, rather than actually allowing this feature to be used on existing code. If I’m understanding correctly they would prefer for the Python grammar to stay the same (hence the comment about updating parsers and IDEs).

But I don’t think I really agree, the extensible annotation syntaxes they mention always feel clunky and awkward to me. For a first-party language feature (especially used as often as this will be), I think dedicated syntax seems right.

Re: PEP 810 – Explicit lazy imports

#49

Post by yegle »

rplnt wrote: post #40

Remember mercurial? Me neither. But what I remeber is this article I've read about all the hacks they had to do to achieve reasonable startup time for CLI in python. And the no #1 cause was loading the whole world you don't ever need. As I recall they somehow monkeypatched the interpreter to ignore imports and just remember their existence until they were actually needed, at which point the import happened. So all th…

I recall chg was a must.

Re: PEP 810 – Explicit lazy imports

#50

Post by Boxxed »

Ugh...I like the idea, but I wish lazy imports were the default. Python allows side effects in the top level though so that would be a breaking change.

Soooo instead now we're going to be in a situation where you're going to be writing "lazy import ..." 99% of the time: unless you're a barbarian, you basically never have side effects at the top level.

Post reply on HN