PEP 810: Update rejected ideas. (#4634)

Author: Yhg1s

peps/pep-0810.rst

@@ -1406,6 +1406,33 @@ 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 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
+*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
+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 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
 -----------------------------------------------------