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

161–170 of 247 posts

Re: PEP 810 – Explicit lazy imports

#161

Post by _ZeD_ »

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

NO! I don't want my source code filled with this crap.

I don't want to lose multiple hours debugging why something did go wrong because I am using three versions of numpy and seven of torch at the same time and there was a mixup

Re: PEP 810 – Explicit lazy imports

#162

Post by _ZeD_ »

veber-alex wrote: post #87
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 would gladly take a command line flag that I can pass to python that makes all module loading lazy. Unless you are writing scripts or very simple stuff running side effects when modules are loaded should be avoided at all cost anyway.

> I would gladly take a command line flag that I can pass to python that makes all module loading lazy.

oh, you want a "break my libraries" flag? :D

seriously, in theory lazy imports may be "transparent" for common use cases, but I've saw too many modules rely on the side effects of the importing, that I understand why they needed to make this a "double opt in" feature

Re: PEP 810 – Explicit lazy imports

#163

Post by gigatexal »

dheera wrote: post #142
gigatexal wrote: post #127

Earlier quoted context omitted.

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

That's messy. I should be able to do "python foo.py" and everything should just work. foo.py should define what it wants and python should fetch it and provide it to foo. I should be able to do "pyc foo.py; ./foo" and everything should just work, dependencies balled up and statically included like Rust or Go. Even NodeJS can turn an entire project into one file to execute. That's what a modern language should look an…

You mean this?

#!/usr/bin/env -S uv run --script # # /// script # requires-python = ">=3.12" # dependencies = ["httpx"] # ///

import httpx

print(httpx.get("https://example.com"))

https://docs.astral.sh/uv/guides/scripts/#improving-reproduc...

There are also projects py2exe pyinstaller iirc and others that try to get the whole static binary thing going.

You’re trying imo to make Python into Golang and if you’re wanting to do that just use Golang. That seems like a far better use of your time.

Re: PEP 810 – Explicit lazy imports

#164

Post by _ZeD_ »

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…

good luck with that syntax - it would be as possible as passing an inline-defined def as parameter instead of a lambda

Re: PEP 810 – Explicit lazy imports

#165

Post by Too »

This is a great compromise given how much would break if this was the default. Making this the default would be better in the long-run, require taming the abuse of side-effects in imports too, win-win.

If one could dream, modules should have to explicitly declare whether they have side-effects or not, with a marker at the top of the module. Not declaring this and trying anything except declaring a function or class should lead to type-checker errors. Modules declaring this pure-marker then automatically become lazy. Others should require explicit "import_with_side_effects" keyword.

    __pure__ = True
    import logging 
    import threading
  
    app = Flask()          #
All of this would be impossible today, given how much the Python relies on metaprogramming. Even standard library exposes functions to create classes on the fly like Enum and dataclasses, that are difficult to assert as either pure or impure. With more and more of the ecosystem embracing typed Python, this metaprogramming is reducing into a less dynamic subset. Type checkers and LSPs must have at least some awareness of these modules, without executing them as plain python-code.

Re: PEP 810 – Explicit lazy imports

#166

Post by ajb »

Given all the problems people are mentioning, it seems like this proposal is on the wrong side. There should be an easy way for a module to declare itself to be lazy loaded. The module author, not the user, is the one who knows whether lazy loading will break stuff.

Re: PEP 810 – Explicit lazy imports

#167

Post by Grikbdl »

ajb wrote: post #166

Given all the problems people are mentioning, it seems like this proposal is on the wrong side. There should be an easy way for a module to declare itself to be lazy loaded. The module author, not the user, is the one who knows whether lazy loading will break stuff.

It's also simpler. It could even be a package level thing similar to typed.py marker. I don't want to pepper literally all my modules with loads of explicit lazy keywords.

Re: PEP 810 – Explicit lazy imports

#168

Post by hnlmorg »

flare_blitz wrote: post #146
jacquesm wrote: post #138

Earlier quoted context omitted.

In spite of the 'You're welcome to bring' this does not actually sound like an encouragement but more of a veiled statement that some non-technical reason will be found to shoot down the proposal if it were to be made so you might as well not bother.

No, the point is that most people in this thread do not appreciate the complexity of implementing lazy imports. If you disagree, your energy is better spent talking to a CPython core developer about implementation details of making baseless assertions from an ivory tower. There are many people here who think enabling lazy imports is as simple as flipping a light switch. They have no idea what they're talking about.

You’ve misread the discussion

This thread was a tangent from lazy imports.

And actually people do appreciate the complexities of changes like this. We were responding to a specific comment that that said “it’s impossible”. Saying something is “possible” isn’t the same as saying “it’s easy”.

Re: PEP 810 – Explicit lazy imports

#169

Post by hnlmorg »

flare_blitz wrote: post #137
hnlmorg wrote: post #117

Earlier quoted context omitted.

Tbh you’re just reinforcing mine and others point there that the issue isn’t a technical one.

"Talk is cheap. Show me the code."

I’m not going to spend an entire weekend drafting a proposal instead of spending time with my kids, just to win “internet points”.

If you want examples then just look at one of the other languages that have implemented compiler / runtime dependency version checks.

Even Go has better dependency resolution than Python, and Go is often the HN poster child for how not to do things.

The crux of the matter is this is a solvable problem. The real issue isn’t that it’s technically impossible, is that it’s not annoying enough of a day to day problem for people who are in a position to influence this change. I’m not that person and don’t aspire to be that person (I have plenty of other projects on my plate as it is)

Re: PEP 810 – Explicit lazy imports

#170

Post by fastasucan »

flare_blitz wrote: post #135
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?…

I also hope this proposal succeeds, but I'm not optimistic. This will break tons of code and introduce a slew of footguns. Import statements fundamentally have side effects, and when and how these side effects are applied will cause mysterious breakages that will keep people up for many nights. This is not fearmongering. There is a reason why the only flavor of Python with lazy imports comes from Meta, which is one o…

They are not entitled to hold the opinion that their imports takes too long, if they dont know the inner workings of pythons import system? Do you listen to yourself?
Post reply on HN