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.

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.

It is a 'soft keyword' as the PEP explains. I would not think that this has any major impact on anyone who just chooses to ignore this feature. Assuming that you want this behavior, I wonder how this could have been done in a better fashion without now having 'lazy' in the specific context of an import statement.

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`.

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/

It should land in 3.15, so October next year. https://peps.python.org/pep-0790/

Quite a few PEPs are accepted this quickly, actually.

But some others take literally years.

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

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

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

Look at the names in the PEP [1], this PEP is written by them

[1] https://peps.python.org/pep-0810/

I'm confused, wouldn't HRT be happy about this? The article you linked specifically states "..we hope to propose a revised lazy imports PEP that introduces an explicit lazy keyword.."

Is that not exactly what PEP 810 proposes?

Why would they? The accepted PEP just has extra keywords to mark imports explicit. That's a source level find-and-replace. They already did most of the real work in their codebase, such as finding where the code depended on the side effect of importing a module.

> I suspect this change in Python will dramatically improve the performance of such large programs as well.

Makes packaging super fun too, where you need to hit every possible path so you don't miss anything imported in 1% of the execution paths :)

You have always been able to do the same thing in Python. This PEP isn't needed for that functionality.

Having some limited experience with lazy imports, yes, but this eliminates a lot of gross boilerplate. It also has the effect of "blessing" the practice of lazy imports which can have a cultural impact; it also prevents a situation wherein multiple subtly incompatible approaches to lazy imports become individually popular.

Not sure that's Occam's razor any more.

Regardless lazy loading needs widespread use to be most effective so having a unified syntax and no extra dependencies makes a lot of sense.

https://peps.python.org/pep-0810/#what-about-star-imports-fr...

> What about star imports (`from module import *`)?

> Wild card (star) imports cannot be lazy - they remain eager. This is because the set of names being imported cannot be determined without loading the module. Using the lazy keyword with star imports will be a syntax error. If lazy imports are globally enabled, star imports will still be eager.

Additionally, star imports can interfere with type checkers and IDEs and shadowing caused by star imports is a frequent and difficult to diagnose source of bugs (you analyze the function you think you're calling and find no issues, but you're actually calling a different function because the star import occurs after your explicit import).

You might be able to workaround this limitation by doing a lazy import into an intermediate module (a prelude) on a name by name basis and then star import that intermediate module. But personally I solve this problem using IDE features.

https://github.com/python-lsp/python-lsp-server/blob/develop...