From 24f168c8a631f7ec501abecaf4d497b78fc88f33 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Mon, 6 Oct 2025 15:44:56 +0200 Subject: [PATCH 1/5] Add the override-global-flag filter to the list of rejected ideas, with rationale. --- peps/pep-0810.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/peps/pep-0810.rst b/peps/pep-0810.rst index c619aaf0954..42038600d36 100644 --- a/peps/pep-0810.rst +++ b/peps/pep-0810.rst @@ -1406,6 +1406,31 @@ confusion about what the default is, or when the ``eager`` keyword would be necessary, or whether it affects lazy imports *in* the explicitly eagerly imported module. +Allowing the filter to force lazy imports even when globally disabled +--------------------------------------------------------------------- + +As lazy imports allow some forms of circular imports that would otherwise +fail, as an intentional and desireable thing (especially for typing-related +imports), the suggestion was made to add a way to override the global +disable, like allowing the lazy imports filter to override the global +disable the way it can override a global enable. The risk here is that we +end up in a confusing situation where some things are overridden and others +are not depending on the relevant priority as we perceive them now, and that +we'll need new ways to disable or enable 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 don't think it's unreasonable as +packages to adopt lazy imports for them to decide to not work with lazy +imports globally disabled, if that's what they want. + +It may be that this means that in time, as more and more packages embrace +both typing and lazy imports, the global disable becomes mostly unused and +unusable. Similar things have happened in the past with other global flags, +and given the low cost of the flag this seems acceptable. It's also a easier +to add more specific re-enabling mechanisms later, when we have a clearer +picture of real-world use and patterns, than it is to remove a hastily added +mechanism that isn't quite right. + Using a context manager instead of a new soft keyword ----------------------------------------------------- From ce8abba0ee0b1084478a3f9a72c3dad73d5336e2 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Mon, 6 Oct 2025 18:30:07 +0200 Subject: [PATCH 2/5] Clarify text. --- peps/pep-0810.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/peps/pep-0810.rst b/peps/pep-0810.rst index 42038600d36..36e55683500 100644 --- a/peps/pep-0810.rst +++ b/peps/pep-0810.rst @@ -1419,9 +1419,9 @@ are not depending on the relevant priority as we perceive them now, and that we'll need new ways to disable or enable 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 don't think it's unreasonable as -packages to adopt lazy imports for them to decide to not work with lazy -imports globally disabled, if that's what they want. +their dependency on lazy imports. We don't think it's unreasonable for +package mantainers, 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 both typing and lazy imports, the global disable becomes mostly unused and From 776008de75afa2de11b2cd663d58294a0245b655 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Mon, 6 Oct 2025 18:31:24 +0200 Subject: [PATCH 3/5] Remove double negative. --- peps/pep-0810.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/peps/pep-0810.rst b/peps/pep-0810.rst index 36e55683500..ae134dfd5de 100644 --- a/peps/pep-0810.rst +++ b/peps/pep-0810.rst @@ -1419,9 +1419,9 @@ are not depending on the relevant priority as we perceive them now, and that we'll need new ways to disable or enable 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 don't think it's unreasonable for -package mantainers, as they update packages to adopt lazy imports, to decide -to *not* support running with lazy imports globally disabled. +their dependency on lazy imports. We think it's reasonable for package +mantainers, 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 both typing and lazy imports, the global disable becomes mostly unused and From b12d3a754d45a12bb0d45beefc6b26ef375d8e87 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Mon, 6 Oct 2025 18:41:41 +0200 Subject: [PATCH 4/5] Address reviewer comments. --- peps/pep-0810.rst | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/peps/pep-0810.rst b/peps/pep-0810.rst index ae134dfd5de..c62b874a5c1 100644 --- a/peps/pep-0810.rst +++ b/peps/pep-0810.rst @@ -1410,14 +1410,16 @@ Allowing the filter to force lazy imports even when globally disabled --------------------------------------------------------------------- As lazy imports allow some forms of circular imports that would otherwise -fail, as an intentional and desireable thing (especially for typing-related -imports), the suggestion was made to add a way to override the global -disable, like allowing the lazy imports filter to override the global -disable the way it can override a global enable. The risk here is that we -end up in a confusing situation where some things are overridden and others -are not depending on the relevant priority as we perceive them now, and that -we'll need new ways to disable or enable as the use of lazy imports evolves. -The global disable is not expected to see commonplace use, but be more of a +fail, as an intentional and desirable thing (especially for typing-related +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 their dependency on lazy imports. We think it's reasonable for package mantainers, as they update packages to adopt lazy imports, to decide to From b1c2a8d7c3168e502a5e34f28772707f95e5f124 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Mon, 6 Oct 2025 18:42:49 +0200 Subject: [PATCH 5/5] Commit suggestion that GitHub somehow lost. --- peps/pep-0810.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-0810.rst b/peps/pep-0810.rst index c62b874a5c1..e32b648a408 100644 --- a/peps/pep-0810.rst +++ b/peps/pep-0810.rst @@ -1428,7 +1428,7 @@ mantainers, as they update packages to adopt lazy imports, to decide to It may be that this means that in time, as more and more packages embrace both typing and lazy imports, the global disable becomes mostly unused and unusable. Similar things have happened in the past with other global flags, -and given the low cost of the flag this seems acceptable. It's also a easier +and given the low cost of the flag this seems acceptable. It's also easier to add more specific re-enabling mechanisms later, when we have a clearer picture of real-world use and patterns, than it is to remove a hastily added mechanism that isn't quite right.