PEP 690: Add "per-module opt-in" to "rejected ideas" section (#2574)

* PEP 690: Add 'per-module opt-in' to rejected ideas

* Update pep-0690.rst

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>

pep-0690.rst

@@ -333,6 +333,31 @@ in the common flow.
 Rejected Ideas
 ==============
 
+Per-module opt-in
+-----------------
+
+A per-module opt-in using e.g. ``from __future__ import lazy_imports`` has a
+couple of disadvantages:
+
+* It is less practical to achieve robust and significant startup-time or
+  memory-use wins by piecemeal application of lazy imports. Generally it would
+  require blanket application of the ``__future__`` import to most of the
+  codebase, as well as to third-party dependencies (which may be hard or
+  impossible.)
+
+* ``__future__`` imports are not feature flags, they are for transition to
+  behaviors which will become default in the future. It is not clear if lazy
+  imports will ever make sense as the default behavior, so we should not
+  promise this with a ``__future__`` import. Thus, a per-module opt-in would
+  require a new ``from __optional_features__ import lazy_imports`` or similar
+  mechanism.
+
+Experience with the reference implementation suggests that the most practical
+adoption path for lazy imports is for a specific deployed application to opt-in
+globally, observe whether anything breaks, and opt-out specific modules as
+needed to account for e.g. reliance on import side effects.
+
+
 Explicit syntax for lazy imports
 --------------------------------