PEP 432: Withdraw to make way for future subproposals (#1476)

While some of the ideas in this PEP are still likely to be pursued in the
future, enough has changed that we expect the specifics will be different
from what I proposed in the original PEP.

pep-0432.txt

@@ -6,13 +6,51 @@ Author: Nick Coghlan <ncoghlan@gmail.com>,
         Victor Stinner <vstinner@python.org>,
         Eric Snow <ericsnowcurrently@gmail.com>
 Discussions-To: capi-sig@python.org
-Status: Draft
+Status: Withdrawn
 Type: Standards Track
 Content-Type: text/x-rst
 Requires: 587
 Created: 28-Dec-2012
-Python-Version: 3.9
+Post-History: 28-Dec-2012, 2-Jan-2013, 30-Mar-2019, 28-Jun-2020
-Post-History: 28-Dec-2012, 2-Jan-2013, 30-Mar-2019
+
+
+PEP Withdrawal
+==============
+
+From late 2012 to mid 2020, this PEP provided general background and specific
+concrete proposals for making the CPython startup sequence easier to maintain
+and the CPython runtime easier to embed as part of a larger application.
+
+For most of that time, the changes were maintained either in a separate feature
+branch, or else as underscore-prefixed private APIs in the main CPython repo.
+
+In 2019, PEP 587 migrated a subset of those API changes to the public CPython
+API for Python 3.8+ (specifically, the PEP updated the interpreter runtime to
+offer an explicitly multi-stage struct-based configuration interface).
+
+In June 2020, in response to a query from the Steering Council, the PEP authors
+decided that it made sense to withdraw the original PEP, as enough has changed
+since PEP 432 was first written that we think any further changes to the
+startup sequence and embedding API would be best formulated as a new PEP (or
+PEPs) that take into account not only the not-yet-implemented ideas from PEP 432
+that weren't considered sufficiently well validated to make their way into
+PEP 587, but also any feedback on the public PEP 587 API, and any other lessons
+that have been learned while adjusting the CPython implementation to be more
+embedding and subinterpreter friendly.
+
+In particular, PEPs proposing the following changes, and any further
+infrastructure changes needed to enable them, would likely still be worth
+exploring:
+
+* shipping an alternate Python executable that ignores all user level
+  settings and runs in isolated mode by default, and would hence be more
+  suitable for execution of system level Python applications than the default
+  interpreter
+* enhancing the zipapp module to support the creation of single-file executables
+  from pure Python scripts (and potentially even Python extension modules, given
+  the introduction of multi-phase extension module initialisation)
+* migrating the complex sys.path initialisation logic from C to Python in order
+  to improve test suite coverage and the general maintainability of that code
 
 
 Abstract
@@ -51,46 +89,6 @@ resolution for most of these should become clearer as the reference
 implementation is developed.
 
 
-PEP Status
-==========
-
-As described further below, the practical constraints on improving the public
-API used to configure an embedded CPython interpreter are currently being
-explored by way of private updates to the initialisation API used by the main
-CPython CLI application.
-
-As long as that is the case, the Discussions-To header in the PEP will remain
-set to ``capi-sig@python.org``.
-
-However, as coherent and feasible proposals to address subsets of the problem
-are identified, they may be spun out to as separate PEPs, which will then be
-added to this PEP as dependencies.
-
-So far, the following subproposals have been extracted:
-
-* PEP 587 (Python Initialization Configuration): this splits out the
-  preinitialization stage, but otherwise keeps the combined ``Py_Initialize*``
-  model that configures a Python interpreter with a ready-to-run ``__main__``
-  module in a single step. While this is still a nice improvement over the
-  pre-PEP status quo and gets embedding applications back on an equal footing
-  with the private APIs exposed to the default CPython CLI in the Python 3.7
-  release, it doesn't yet allow for more of the configuration code to be
-  migrated out of C and into frozen Python modules.
-
-For PEP 432 itself, it is now expected that once enough subproposals are
-eventually split out, the only things left to be propose in PEP 432 itself will
-be actually shipping a ``system-python`` executable (which would run in isolated
-mode by default and ignore all user-level settings) and enhancing the ``zipapp``
-module to support the creation of single-file executables from pure Python
-scripts. Once that is the case, the ``Discussions-To`` PEP header will be
-removed, and the PEP will be submitted back to ``python-dev`` for further
-discussion.
-
-In the meantime, the PEP will continue to be used as a draft specification for
-the aspects of the proposed startup sequence redesign that don't yet have their
-own dedicated PEP.
-
-
 Proposal
 ========