Skip to content

PEP 810 - Fix typos #4638

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
pablogsal merged 1 commit into from
Oct 6, 2025
Merged

PEP 810 - Fix typos #4638

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions peps/pep-0810.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1443,7 +1443,7 @@ Alternate keyword names
-----------------------

For this PEP, we decided to propose ``lazy`` for the explicit keyword as it
felt the most familar to those already focused on optimizing import overhead.
felt the most familiar to those already focused on optimizing import overhead.
We also considered a variety of other options to support explicit lazy
imports. The most compelling alternates were ``defer`` and ``delay``.

Expand Down Expand Up @@ -1541,14 +1541,14 @@ imports), there was a suggestion to add a way to override the global disable
and force particular imports to be lazy, for instance by calling the lazy
imports filter even if lazy imports are globally disabled.

This approach could a complex hierarchy of the different "override" systems,
making it much harder to analyze and reason about the code. Additionally,
this may require additional complexity to introduce finer-grained systems to
enable or disable particular imports as the use of lazy imports evolves. The
global disable is not expected to see commonplace use, but be more of a
debugging and selective testing tool for those who want to tightly control
This approach could introduce a complex hierarchy of the different "override"
systems, making it much harder to analyze and reason about the code.
Additionally, this may require additional complexity to introduce finer-grained
systems to enable or disable particular imports as the use of lazy imports
evolves. The global disable is not expected to see commonplace use, but be more
of a debugging and selective testing tool for those who want to tightly control
their dependency on lazy imports. We think it's reasonable for package
mantainers, as they update packages to adopt lazy imports, to decide to
maintainers, as they update packages to adopt lazy imports, to decide to
*not* support running with lazy imports globally disabled.

It may be that this means that in time, as more and more packages embrace
Expand All @@ -1573,7 +1573,7 @@ has been proposed:
This would replace the need for :data:`!__lazy_modules__`, and allow
libraries to use one of the existing lazy imports implementations in older
Python versions. However, adding magic ``with`` statements with that kind of
effect would be a signficant change to Python and ``with`` statements in
effect would be a significant change to Python and ``with`` statements in
general, and it would not be easy to combine with the implementation for
lazy imports in this proposal. Adding standard library support for existing
lazy importers *without* changes to the implementation amounts to the status
Expand Down