From ba857a6389e8e8c8a08fb10b8caa63e18ed6d070 Mon Sep 17 00:00:00 2001 From: Carl Meyer Date: Tue, 3 May 2022 15:25:26 -0600 Subject: [PATCH] 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 Co-authored-by: Jelle Zijlstra --- pep-0690.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/pep-0690.rst b/pep-0690.rst index 4c35c710f5e..8c45104030a 100644 --- a/pep-0690.rst +++ b/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 --------------------------------