Add the override-global-flag filter to the list of rejected ideas, with

rationale.

Author: Yhg1s

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