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

181–190 of 247 posts

Re: PEP 810 – Explicit lazy imports

#181

Post by IshKebab »

flare_blitz wrote: post #134
IshKebab wrote: post #96

Earlier quoted context omitted.

Nope. Relative imports work by relative package path, which is not at all the same. Often when you run Python you don't even have a package path. Using `importlib` is a horrible hack that breaks basically all tooling. You very very obviously are not supposed to do that.

> Using `importlib` is a horrible hack that breaks basically all tooling. You very very obviously are not supposed to do that. This is an assertion that has absolutely no reasoning behind it. I'm not saying I disagree; I'm just saying there is a time and a place for importlib.

Well not if you want high quality Python code. Pylint and Pyright won't understand it, and those are absolutely critical to writing Python code that works reliably.

Re: PEP 810 – Explicit lazy imports

#182

Post by flare_blitz »

fastasucan wrote: post #170
flare_blitz wrote: post #135

Earlier quoted context omitted.

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?

That’s not what I said. Nobody is “entitled” or “not entitled” to hold certain opinions. Please reread my original comment carefully.

Re: PEP 810 – Explicit lazy imports

#183

Post by [deleted] »

hnlmorg wrote: post #169
flare_blitz wrote: post #137

Earlier quoted context omitted.

"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 sol…

[deleted]

Re: PEP 810 – Explicit lazy imports

#184

Post by IshKebab »

flykespice wrote: post #145
zahlman wrote: post #70

Earlier quoted context omitted.

Recursively importing other modules is itself a side effect. In fact, all the code you see in the module is "side effects", in a sense. A `class` body, for example, has to actually run at import time, creating the class object and attaching it as an attribute of the module object. Similarly for functions. Even a simple assignment of a constant actually has to run at module import. And all of these things add up. Furt…

Side-effect means you're changing state outside the scope the code is running. Sure thing you can declare globals variable and run anything on a module file global scope (outside funcs and class body), but even that 'global' scope is just an illusion, and everything declared there, as yourself said, is scoped to the module's namespace (and you can't leak the 'globals' when importing the module unless you explicity do…

Often it's things like registering functions in a global registry, or patching things about how Python works (e.g. adding stuff to the module path).

Re: PEP 810 – Explicit lazy imports

#185

Post by uncletoxa »

flare_blitz wrote: post #156
WD-42 wrote: post #154

Earlier quoted context omitted.

Some of these worries make sense, but wouldn’t it be relatively trivial to pass a flag to the interpreter or something similar in order to force all imports to evaluate, as in the current behavior? But to be a bit cheeky if some of these issues cause serious production outages for you it might be time to consider moving on from a scripting language altogether.

The issue is that some imports can be made lazy and some cannot. A binaristic all-or-nothing approach does not address the issue. (I also think that there is zero basis to claim that adding such a flag is trivial, since there’s no reference implementation of this flavor of lazy imports.) What if we have a program where one feature works only when lazy imports are enabled and one feature only when lazy imports are dis…

Theoretically the implementation may use the approach "as lazy as possible". Traverse lazy imports until you encounter a regular one. I doubt it will make much difference, but at least it gives an option.

Re: PEP 810 – Explicit lazy imports

#186

Post by paffdragon »

flare_blitz wrote: post #156
WD-42 wrote: post #154

Earlier quoted context omitted.

Some of these worries make sense, but wouldn’t it be relatively trivial to pass a flag to the interpreter or something similar in order to force all imports to evaluate, as in the current behavior? But to be a bit cheeky if some of these issues cause serious production outages for you it might be time to consider moving on from a scripting language altogether.

The issue is that some imports can be made lazy and some cannot. A binaristic all-or-nothing approach does not address the issue. (I also think that there is zero basis to claim that adding such a flag is trivial, since there’s no reference implementation of this flavor of lazy imports.) What if we have a program where one feature works only when lazy imports are enabled and one feature only when lazy imports are dis…

Maybe the package that requires lazy can somehow declare that requirement, so another package that tries to force not lazy will fail early and realize it needs to replace this dependency with something compatible or change its ways. It definitely adds complexity, though.

Re: PEP 810 – Explicit lazy imports

#187

Post by kstrauser »

flykespice wrote: post #145
zahlman wrote: post #70

Earlier quoted context omitted.

Recursively importing other modules is itself a side effect. In fact, all the code you see in the module is "side effects", in a sense. A `class` body, for example, has to actually run at import time, creating the class object and attaching it as an attribute of the module object. Similarly for functions. Even a simple assignment of a constant actually has to run at module import. And all of these things add up. Furt…

Side-effect means you're changing state outside the scope the code is running. Sure thing you can declare globals variable and run anything on a module file global scope (outside funcs and class body), but even that 'global' scope is just an illusion, and everything declared there, as yourself said, is scoped to the module's namespace (and you can't leak the 'globals' when importing the module unless you explicity do…

You’re right. “Side effect” here means that your program’s behavior changes simply by importing something, eg by monkey patching something else.

If’s not:

* Importing other modules.

* Taking a long time to import.

* Writing .pyc files.

If any program can “import foo” and still execute exactly the same bytecode afterward as before, you can say that foo doesn’t have side effects.

Re: PEP 810 – Explicit lazy imports

#188

Post by cuu508 »

paffdragon wrote: post #186
flare_blitz wrote: post #156

Earlier quoted context omitted.

The issue is that some imports can be made lazy and some cannot. A binaristic all-or-nothing approach does not address the issue. (I also think that there is zero basis to claim that adding such a flag is trivial, since there’s no reference implementation of this flavor of lazy imports.) What if we have a program where one feature works only when lazy imports are enabled and one feature only when lazy imports are dis…

Maybe the package that requires lazy can somehow declare that requirement, so another package that tries to force not lazy will fail early and realize it needs to replace this dependency with something compatible or change its ways. It definitely adds complexity, though.

Or check at runtime if it's running with the lazy import feature active. Then instead of breaking in mysterious ways in production it would crash on startup, during development.

Re: PEP 810 – Explicit lazy imports

#189

Post by mekoka »

johnfn wrote: post #126
mekoka wrote: post #119

Earlier quoted context omitted.

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.

Re: PEP 810 – Explicit lazy imports

#190

Post by peterfirefly »

simonw wrote: post #179
Inufu wrote: post #174

Earlier quoted context omitted.

In that case the CLI only needs to import the plugin that defined that sub command, not all plugins?

It doesn't know which plugin defines a subcommand until it imports the plugin's module. I'm happy with the solution I have now, which is to encourage plugin authors not to import PyTorch or other heavy dependencies at the root level of their plugin code.

> It doesn't know which plugin defines a subcommand until it imports the plugin's module.

That might be considered a design mistake -- one that should be easy to migrate away from.

You won't need to do anything, of course, if the lazy import becomes available on common Python installs some day in the future. That might take years, though.

Post reply on HN