Hacker News Reader

Comment by comex | Hacker News Reader

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. That would simplify things since only large libraries would have to care about laziness. To be fair, in such a design, the interpreter would have to eagerly look up imports on the filesystem to decide whether they should be lazy-loaded. And there are probably other downsides I'm not thinking of.

View on HN

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 :)

The paradigm I'm alluding to is eager to lazy, not 2 to 3. E.g. dict.items() in v3 works like dict.iteritems() in v2.

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.

People said the same about Perl and its “there’s more than one way to do things” ethos, which gained much criticism.

Same is true for C++.

In this specific case, I think a lazy load directive isn’t a bad addition. But one does need to be careful about adding new language features just because you have an active community.

Perhaps people won't use it. But I for one want it to be used, and I will certainly be using it in my own code if the PEP is accepted. Startup time is very important to me, more important than the cost of making the code noisier. I just wish I didn't have to make that tradeoff in the first place.

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.

That's already part of the PIP. There is a flag to enable lazy imports for all possible imports.

The PEP includes the ability to enable (or disable) lazy imports globally via a command-line flag or environment variable, in addition to the import syntax.

> 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

You can do it today with a few lines of code, although the implementation I show is not particularly robust (since it works by metaprogramming the import system, of course other code could interfere): https://news.ycombinator.com/item?id=45467489

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.

I think side-effects are exactly the problem, you can't have the runtime default to lazy-loading all modules without breaking code that e.g. relies on side effects running before thread creation or forking.

> Even if it has side effects the caller may want to defer those as well.

But that's rare, and could be handled with existing workarounds.

Normally, a module needs to be eagerly imported if and only if it has side effects.

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

I don't follow your reasoning. `pyproject.toml` has nothing to do with what happens at runtime. It's about building and packaging the code. It also doesn't say anything related to the modules that will be imported at runtime. It deals in the names of distributions, which are completely independent of `import` statements.

What I mean is that the `lazy` keyword need not be specified in the source Python files. Instead you can mark off a bunch of modules identified by regex as lazy. Perhaps `pyproject.toml` isn't the best place and it should be an independent python file.

The issue is that Python code may validly stand apart from `pyproject.toml` or any other metadata.

Reply on news.ycombinator.com