Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

discuss.python.org

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#41

Post by striking »

nothrowaways wrote: post #31

Python is quickly turning into a crowded keyword junkyard

From the PEP (https://peps.python.org/pep-0810/):

> The choice to introduce a new `lazy` keyword reflects the need for explicit syntax. Lazy imports have different semantics from normal imports: errors and side effects occur at first use rather than at the import statement. This semantic difference makes it critical that laziness is visible at the import site itself, not hidden in global configuration or distant module-level declarations. The lazy keyword provides local reasoning about import behavior, avoiding the need to search elsewhere in the code to understand whether an import is deferred. The rest of the import semantics remain unchanged: the same import machinery, module finding, and loading mechanisms are used.

This functionality is highly desired, and it does appear to actually need a new (soft) keyword. Sorry you don't like it.

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#42

Post by onedognight »

nothrowaways wrote: post #31

Python is quickly turning into a crowded keyword junkyard

The pep didn’t mention considering reusing `async` instead of `lazy`. That would’ve conveyed the same thing to me without a new keyword, and would haven’t been similar to html’s usage `async`.

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#43

Post by lolpython »

NooneAtAll3 wrote: post #40
lolpython wrote: post #4

Earlier quoted context omitted.

HN is using the canonical URL for the page. See https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

so it's a misconfig on python.org side?

I think so? It caused the same issue when I cross posted to Lobste.rs

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#44

Post by lairv »

notatallshaw wrote: post #35
nothrowaways wrote: post #31

Python is quickly turning into a crowded keyword junkyard

Python has about 40 keywords, I say I would regularly use about 30, and irregularly use about another 5. Hardly seems like a "junkyard". Further, this lack of first class support for lazy importing has spawned multiple CPython forks that implement their own lazy importing or a modified version of the prior rejected PEP 690. Reducing the real world need for forks seems worth the price of one keyword.

For those curious here are the actual keywords (from https://docs.python.org/3/reference/lexical_analysis.html?ut... )

Hard Keywords:

False await else import pass None break except in raise True class finally is return and continue for lambda try as def from nonlocal while assert del global not with async elif if or yield

Soft Keywords:

match case _ type

I think nonlocal/global are the only hard keywords I now barely use, for the soft ones I rarely use pattern matching, so 5 seems like a good estimate

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#45

Post by cgriswald »

swiftcoder wrote: post #36
ant6n wrote: post #28

Next we need lazy import *

Is that not the purpose of the global switch outlined in the PEP?

No. From the PEP:

  Where  can be:
  
      "normal" (or unset): Only explicitly marked lazy imports are lazy
      "all": All module-level imports (except in try blocks and import *) become   potentially lazy
      "none": No imports are lazy, even those explicitly marked with lazy keyword

  When the global flag is set to "all", all imports at the global level of all modules are potentially lazy except for those inside a try block or any wild card (from ... import *) import.

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#46

Post by snovv_crash »

falcor84 wrote: post #37
Figs wrote: post #30

Earlier quoted context omitted.

Depends if your code has horrors like this lurking in it: m = importlib.import_module(requests.get("http://localhost:8000/package_name").content.strip().decode("ASCII"))

If you want even better nightmares, you can make localhost:8000 forward to a container running claude code with --dangerously-skip-permissions which uses an unkindness of mcp servers to control that endpoint on the fly based (amongst other sources) on 4chan's /b/.

Better to let the viewers on a twitch stream vote for it.

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#48

Post by zahlman »

jauntywundrkind wrote: post #9

Source phase imports are stage 3 (recommended for implementation, no major updates expected) in JS. "Import source" tells the runtime to go get the code, but not yet run it. Similar ideas seemingly to what's going on here in python! https://github.com/tc39/proposal-source-phase-imports

This proposal defers even looking for the code. The LazyLoader already in the standard library would eagerly look for code, but just record a file path and not actually store any bytecode data, never mind deserializing or running it.

The rationale described in the PEP is that some systems try to `import`, for example, across a network share, so even searching the filesystem is slow and there is a desire to defer that (and avoid it on runs where the corresponding code isn't executed).

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#49

Post by zahlman »

falcor84 wrote: post #37
Figs wrote: post #30

Earlier quoted context omitted.

Depends if your code has horrors like this lurking in it: m = importlib.import_module(requests.get("http://localhost:8000/package_name").content.strip().decode("ASCII"))

If you want even better nightmares, you can make localhost:8000 forward to a container running claude code with --dangerously-skip-permissions which uses an unkindness of mcp servers to control that endpoint on the fly based (amongst other sources) on 4chan's /b/.

> which uses an unkindness of mcp servers

I guess you meant "a feature of MCP servers which is unkind", but I couldn't help but interpret "unkindness" as the collective noun for a group of MCP servers.

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#50

Post by zahlman »

johnfn wrote: post #11

This will be huge at the place I work! I’m unfamiliar with the PEP process. How long until this makes it into a Python version?

This one is scheduled to land in the next "minor" version, 3.15. Python has an annual release cadence; 3.14 came out recently and 3.15 is due next October.

In general, most PEPs are authored targeting the "next minor version" at the time of proposal; but they may be intentionally deferred at the start, and sometimes the process can take multiple years anyway.

There are also PEPs that don't involve any change to the Python language, standard library or interpreter. In particular, there are PEPs that exist simply to document existing practice (or changes thereto), PEPs that concern governance (the Python Software Foundation, the Steering Council etc.), and PEPs that cover related special interests, such as packaging standards (which in turn can range from technical details about how metadata is formatted, to changes in PyPI's API).

https://peps.python.org/pep-0000/

Post reply on HN