CINXE.COM

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="color-scheme" content="light dark"> <title>PEP 408 – Standard library __preview__ package | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0408/"> <link rel="stylesheet" href="../_static/style.css" type="text/css"> <link rel="stylesheet" href="../_static/mq.css" type="text/css"> <link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light"> <link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark"> <link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss"> <meta property="og:title" content='PEP 408 – Standard library __preview__ package | peps.python.org'> <meta property="og:description" content="The process of including a new module into the Python standard library is hindered by the API lock-in and promise of backward compatibility implied by a module being formally part of Python. This PEP proposes a transitional state for modules - inclusio..."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0408/"> <meta property="og:site_name" content="Python Enhancement Proposals (PEPs)"> <meta property="og:image" content="https://peps.python.org/_static/og-image.png"> <meta property="og:image:alt" content="Python PEPs"> <meta property="og:image:width" content="200"> <meta property="og:image:height" content="200"> <meta name="description" content="The process of including a new module into the Python standard library is hindered by the API lock-in and promise of backward compatibility implied by a module being formally part of Python. This PEP proposes a transitional state for modules - inclusio..."> <meta name="theme-color" content="#3776ab"> </head> <body> <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all"> <title>Following system colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="9"></circle> <path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path> </svg> </symbol> <symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all"> <title>Selected dark colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <path stroke="none" d="M0 0h24v24H0z" fill="none"></path> <path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path> </svg> </symbol> <symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all"> <title>Selected light colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="5"></circle> <line x1="12" y1="1" x2="12" y2="3"></line> <line x1="12" y1="21" x2="12" y2="23"></line> <line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line> <line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line> <line x1="1" y1="12" x2="3" y2="12"></line> <line x1="21" y1="12" x2="23" y2="12"></line> <line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line> <line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line> </svg> </symbol> </svg> <script> document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto" </script> <section id="pep-page-section"> <header> <h1>Python Enhancement Proposals</h1> <ul class="breadcrumbs"> <li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li> <li><a href="../pep-0000/">PEP Index</a> » </li> <li>PEP 408</li> </ul> <button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())"> <svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg> <span class="visually-hidden">Toggle light / dark / auto colour theme</span> </button> </header> <article> <section id="pep-content"> <h1 class="page-title">PEP 408 – Standard library __preview__ package</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author<span class="colon">:</span></dt> <dd class="field-odd">Alyssa Coghlan <ncoghlan at gmail.com>, Eli Bendersky <eliben at gmail.com></dd> <dt class="field-even">Status<span class="colon">:</span></dt> <dd class="field-even"><abbr title="Formally declined and will not be accepted">Rejected</abbr></dd> <dt class="field-odd">Type<span class="colon">:</span></dt> <dd class="field-odd"><abbr title="Normative PEP with a new feature for Python, implementation change for CPython or interoperability standard for the ecosystem">Standards Track</abbr></dd> <dt class="field-even">Created<span class="colon">:</span></dt> <dd class="field-even">07-Jan-2012</dd> <dt class="field-odd">Python-Version<span class="colon">:</span></dt> <dd class="field-odd">3.3</dd> <dt class="field-even">Post-History<span class="colon">:</span></dt> <dd class="field-even">27-Jan-2012</dd> <dt class="field-odd">Resolution<span class="colon">:</span></dt> <dd class="field-odd"><a class="reference external" href="https://mail.python.org/pipermail/python-dev/2012-January/115962.html">Python-Dev message</a></dd> </dl> <hr class="docutils" /> <section id="contents"> <details><summary>Table of Contents</summary><ul class="simple"> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#pep-rejection">PEP Rejection</a></li> <li><a class="reference internal" href="#proposal-the-preview-package">Proposal - the __preview__ package</a><ul> <li><a class="reference internal" href="#which-modules-should-go-through-preview">Which modules should go through <code class="docutils literal notranslate"><span class="pre">__preview__</span></code></a></li> <li><a class="reference internal" href="#criteria-for-graduation">Criteria for “graduation”</a></li> <li><a class="reference internal" href="#example">Example</a></li> </ul> </li> <li><a class="reference internal" href="#rationale">Rationale</a><ul> <li><a class="reference internal" href="#benefits-for-the-core-development-team">Benefits for the core development team</a></li> <li><a class="reference internal" href="#benefits-for-end-users">Benefits for end users</a></li> </ul> </li> <li><a class="reference internal" href="#candidates-for-inclusion-into-preview">Candidates for inclusion into __preview__</a></li> <li><a class="reference internal" href="#relationship-with-pep-407">Relationship with PEP 407</a></li> <li><a class="reference internal" href="#rejected-alternatives-and-variations">Rejected alternatives and variations</a><ul> <li><a class="reference internal" href="#using-future">Using <code class="docutils literal notranslate"><span class="pre">__future__</span></code></a></li> <li><a class="reference internal" href="#versioning-the-package">Versioning the package</a></li> <li><a class="reference internal" href="#using-a-package-name-without-leading-and-trailing-underscores">Using a package name without leading and trailing underscores</a></li> <li><a class="reference internal" href="#preserving-pickle-compatibility">Preserving pickle compatibility</a></li> </ul> </li> <li><a class="reference internal" href="#credits">Credits</a></li> <li><a class="reference internal" href="#references">References</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> <p>The process of including a new module into the Python standard library is hindered by the API lock-in and promise of backward compatibility implied by a module being formally part of Python. This PEP proposes a transitional state for modules - inclusion in a special <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> package for the duration of a minor release (roughly 18 months) prior to full acceptance into the standard library. On one hand, this state provides the module with the benefits of being formally part of the Python distribution. On the other hand, the core development team explicitly states that no promises are made with regards to the module’s eventual full inclusion into the standard library, or to the stability of its API, which may change for the next release.</p> </section> <section id="pep-rejection"> <h2><a class="toc-backref" href="#pep-rejection" role="doc-backlink">PEP Rejection</a></h2> <p>Based on his experience with a similar “labs” namespace in Google App Engine, Guido has rejected this PEP <a class="footnote-reference brackets" href="#id8" id="id1">[3]</a> in favour of the simpler alternative of explicitly marking provisional modules as such in their documentation.</p> <p>If a module is otherwise considered suitable for standard library inclusion, but some concerns remain regarding maintainability or certain API details, then the module can be accepted on a provisional basis. While it is considered an unlikely outcome, such modules <em>may</em> be removed from the standard library without a deprecation period if the lingering concerns prove well-founded.</p> <p>As part of the same announcement, Guido explicitly accepted Matthew Barnett’s ‘regex’ module <a class="footnote-reference brackets" href="#id9" id="id2">[4]</a> as a provisional addition to the standard library for Python 3.3 (using the ‘regex’ name, rather than as a drop-in replacement for the existing ‘re’ module).</p> </section> <section id="proposal-the-preview-package"> <h2><a class="toc-backref" href="#proposal-the-preview-package" role="doc-backlink">Proposal - the __preview__ package</a></h2> <p>Whenever the Python core development team decides that a new module should be included into the standard library, but isn’t entirely sure about whether the module’s API is optimal, the module can be placed in a special package named <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> for a single minor release.</p> <p>In the next minor release, the module may either be “graduated” into the standard library (and occupy its natural place within its namespace, leaving the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> package), or be rejected and removed entirely from the Python source tree. If the module ends up graduating into the standard library after spending a minor release in <code class="docutils literal notranslate"><span class="pre">__preview__</span></code>, its API may be changed according to accumulated feedback. The core development team explicitly makes no guarantees about API stability and backward compatibility of modules in <code class="docutils literal notranslate"><span class="pre">__preview__</span></code>.</p> <p>Entry into the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> package marks the start of a transition of the module into the standard library. It means that the core development team assumes responsibility of the module, similarly to any other module in the standard library.</p> <section id="which-modules-should-go-through-preview"> <h3><a class="toc-backref" href="#which-modules-should-go-through-preview" role="doc-backlink">Which modules should go through <code class="docutils literal notranslate"><span class="pre">__preview__</span></code></a></h3> <p>We expect most modules proposed for addition into the Python standard library to go through a minor release in <code class="docutils literal notranslate"><span class="pre">__preview__</span></code>. There may, however, be some exceptions, such as modules that use a pre-defined API (for example <code class="docutils literal notranslate"><span class="pre">lzma</span></code>, which generally follows the API of the existing <code class="docutils literal notranslate"><span class="pre">bz2</span></code> module), or modules with an API that has wide acceptance in the Python development community.</p> <p>In any case, modules that are proposed to be added to the standard library, whether via <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> or directly, must fulfill the acceptance conditions set by <a class="pep reference internal" href="../pep-0002/" title="PEP 2 – Procedure for Adding New Modules">PEP 2</a>.</p> <p>It is important to stress that the aim of this proposal is not to make the process of adding new modules to the standard library more difficult. On the contrary, it tries to provide a means to add <em>more</em> useful libraries. Modules which are obvious candidates for entry can be added as before. Modules which due to uncertainties about the API could be stalled for a long time now have a means to still be distributed with Python, via an incubation period in the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> package.</p> </section> <section id="criteria-for-graduation"> <h3><a class="toc-backref" href="#criteria-for-graduation" role="doc-backlink">Criteria for “graduation”</a></h3> <p>In principle, most modules in the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> package should eventually graduate to the stable standard library. Some reasons for not graduating are:</p> <ul class="simple"> <li>The module may prove to be unstable or fragile, without sufficient developer support to maintain it.</li> <li>A much better alternative module may be found during the preview release</li> </ul> <p>Essentially, the decision will be made by the core developers on a per-case basis. The point to emphasize here is that a module’s appearance in the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> package in some release does not guarantee it will continue being part of Python in the next release.</p> </section> <section id="example"> <h3><a class="toc-backref" href="#example" role="doc-backlink">Example</a></h3> <p>Suppose the <code class="docutils literal notranslate"><span class="pre">example</span></code> module is a candidate for inclusion in the standard library, but some Python developers aren’t convinced that it presents the best API for the problem it intends to solve. The module can then be added to the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> package in release <code class="docutils literal notranslate"><span class="pre">3.X</span></code>, importable via:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span><span class="w"> </span><span class="nn">__preview__</span><span class="w"> </span><span class="kn">import</span> <span class="n">example</span> </pre></div> </div> <p>Assuming the module is then promoted to the standard library proper in release <code class="docutils literal notranslate"><span class="pre">3.X+1</span></code>, it will be moved to a permanent location in the library:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">import</span><span class="w"> </span><span class="nn">example</span> </pre></div> </div> <p>And importing it from <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> will no longer work.</p> </section> </section> <section id="rationale"> <h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2> <section id="benefits-for-the-core-development-team"> <h3><a class="toc-backref" href="#benefits-for-the-core-development-team" role="doc-backlink">Benefits for the core development team</a></h3> <p>Currently, the core developers are really reluctant to add new interfaces to the standard library. This is because as soon as they’re published in a release, API design mistakes get locked in due to backward compatibility concerns.</p> <p>By gating all major API additions through some kind of a preview mechanism for a full release, we get one full release cycle of community feedback before we lock in the APIs with our standard backward compatibility guarantee.</p> <p>We can also start integrating preview modules with the rest of the standard library early, so long as we make it clear to packagers that the preview modules should not be considered optional. The only difference between preview APIs and the rest of the standard library is that preview APIs are explicitly exempted from the usual backward compatibility guarantees.</p> <p>Essentially, the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> package is intended to lower the risk of locking in minor API design mistakes for extended periods of time. Currently, this concern can block new additions, even when the core development team consensus is that a particular addition is a good idea in principle.</p> </section> <section id="benefits-for-end-users"> <h3><a class="toc-backref" href="#benefits-for-end-users" role="doc-backlink">Benefits for end users</a></h3> <p>For future end users, the broadest benefit lies in a better “out-of-the-box” experience - rather than being told “oh, the standard library tools for task X are horrible, download this 3rd party library instead”, those superior tools are more likely to be just be an import away.</p> <p>For environments where developers are required to conduct due diligence on their upstream dependencies (severely harming the cost-effectiveness of, or even ruling out entirely, much of the material on PyPI), the key benefit lies in ensuring that anything in the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> package is clearly under python-dev’s aegis from at least the following perspectives:</p> <ul class="simple"> <li>Licensing: Redistributed by the PSF under a Contributor Licensing Agreement.</li> <li>Documentation: The documentation of the module is published and organized via the standard Python documentation tools (i.e. ReST source, output generated with Sphinx and published on <a class="reference external" href="http://docs.python.org">http://docs.python.org</a>).</li> <li>Testing: The module test suites are run on the python.org buildbot fleet and results published via <a class="reference external" href="http://www.python.org/dev/buildbot">http://www.python.org/dev/buildbot</a>.</li> <li>Issue management: Bugs and feature requests are handled on <a class="reference external" href="http://bugs.python.org">http://bugs.python.org</a></li> <li>Source control: The master repository for the software is published on <a class="reference external" href="http://hg.python.org">http://hg.python.org</a>.</li> </ul> </section> </section> <section id="candidates-for-inclusion-into-preview"> <h2><a class="toc-backref" href="#candidates-for-inclusion-into-preview" role="doc-backlink">Candidates for inclusion into __preview__</a></h2> <p>For Python 3.3, there are a number of clear current candidates:</p> <ul class="simple"> <li><code class="docutils literal notranslate"><span class="pre">regex</span></code> (<a class="reference external" href="http://pypi.python.org/pypi/regex">http://pypi.python.org/pypi/regex</a>)</li> <li><code class="docutils literal notranslate"><span class="pre">daemon</span></code> (<a class="pep reference internal" href="../pep-3143/" title="PEP 3143 – Standard daemon process library">PEP 3143</a>)</li> <li><code class="docutils literal notranslate"><span class="pre">ipaddr</span></code> (<a class="pep reference internal" href="../pep-3144/" title="PEP 3144 – IP Address Manipulation Library for the Python Standard Library">PEP 3144</a>)</li> </ul> <p>Other possible future use cases include:</p> <ul class="simple"> <li>Improved HTTP modules (e.g. <code class="docutils literal notranslate"><span class="pre">requests</span></code>)</li> <li>HTML 5 parsing support (e.g. <code class="docutils literal notranslate"><span class="pre">html5lib</span></code>)</li> <li>Improved URL/URI/IRI parsing</li> <li>A standard image API (<a class="pep reference internal" href="../pep-0368/" title="PEP 368 – Standard image protocol and class">PEP 368</a>)</li> <li>Encapsulation of the import state (<a class="pep reference internal" href="../pep-0368/" title="PEP 368 – Standard image protocol and class">PEP 368</a>)</li> <li>Standard event loop API (<a class="pep reference internal" href="../pep-3153/" title="PEP 3153 – Asynchronous IO support">PEP 3153</a>)</li> <li>A binary version of WSGI for Python 3 (e.g. <a class="pep reference internal" href="../pep-0444/" title="PEP 444 – Python Web3 Interface">PEP 444</a>)</li> <li>Generic function support (e.g. <code class="docutils literal notranslate"><span class="pre">simplegeneric</span></code>)</li> </ul> </section> <section id="relationship-with-pep-407"> <h2><a class="toc-backref" href="#relationship-with-pep-407" role="doc-backlink">Relationship with PEP 407</a></h2> <p><a class="pep reference internal" href="../pep-0407/" title="PEP 407 – New release cycle and introducing long-term support versions">PEP 407</a> proposes a change to the core Python release cycle to permit interim releases every 6 months (perhaps limited to standard library updates). If such a change to the release cycle is made, the following policy for the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> namespace is suggested:</p> <ul class="simple"> <li>For long-term support releases, the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> namespace would always be empty.</li> <li>New modules would be accepted into the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> namespace only in interim releases that immediately follow a long-term support release.</li> <li>All modules added will either be migrated to their final location in the standard library or dropped entirely prior to the next long-term support release.</li> </ul> </section> <section id="rejected-alternatives-and-variations"> <h2><a class="toc-backref" href="#rejected-alternatives-and-variations" role="doc-backlink">Rejected alternatives and variations</a></h2> <section id="using-future"> <h3><a class="toc-backref" href="#using-future" role="doc-backlink">Using <code class="docutils literal notranslate"><span class="pre">__future__</span></code></a></h3> <p>Python already has a “forward-looking” namespace in the form of the <code class="docutils literal notranslate"><span class="pre">__future__</span></code> module, so it’s reasonable to ask why that can’t be re-used for this new purpose.</p> <p>There are two reasons why doing so not appropriate:</p> <p>1. The <code class="docutils literal notranslate"><span class="pre">__future__</span></code> module is actually linked to a separate compiler directives feature that can actually change the way the Python interpreter compiles a module. We don’t want that for the preview package - we just want an ordinary Python package.</p> <p>2. The <code class="docutils literal notranslate"><span class="pre">__future__</span></code> module comes with an express promise that names will be maintained in perpetuity, long after the associated features have become the compiler’s default behaviour. Again, this is precisely the opposite of what is intended for the preview package - it is almost certain that all names added to the preview will be removed at some point, most likely due to their being moved to a permanent home in the standard library, but also potentially due to their being reverted to third party package status (if community feedback suggests the proposed addition is irredeemably broken).</p> </section> <section id="versioning-the-package"> <h3><a class="toc-backref" href="#versioning-the-package" role="doc-backlink">Versioning the package</a></h3> <p>One proposed alternative <a class="footnote-reference brackets" href="#id6" id="id3">[1]</a> was to add explicit versioning to the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> package, i.e. <code class="docutils literal notranslate"><span class="pre">__preview34__</span></code>. We think that it’s better to simply define that a module being in <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> in Python 3.X will either graduate to the normal standard library namespace in Python 3.X+1 or will disappear from the Python source tree altogether. Versioning the <code class="docutils literal notranslate"><span class="pre">_preview__</span></code> package complicates the process and does not align well with the main intent of this proposal.</p> </section> <section id="using-a-package-name-without-leading-and-trailing-underscores"> <h3><a class="toc-backref" href="#using-a-package-name-without-leading-and-trailing-underscores" role="doc-backlink">Using a package name without leading and trailing underscores</a></h3> <p>It was proposed <a class="footnote-reference brackets" href="#id6" id="id4">[1]</a> to use a package name like <code class="docutils literal notranslate"><span class="pre">preview</span></code> or <code class="docutils literal notranslate"><span class="pre">exp</span></code>, instead of <code class="docutils literal notranslate"><span class="pre">__preview__</span></code>. This was rejected in the discussion due to the special meaning a “dunder” package name (that is, a name <em>with</em> leading and trailing double-underscores) conveys in Python. Besides, a non-dunder name would suggest normal standard library API stability guarantees, which is not the intention of the <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> package.</p> </section> <section id="preserving-pickle-compatibility"> <h3><a class="toc-backref" href="#preserving-pickle-compatibility" role="doc-backlink">Preserving pickle compatibility</a></h3> <p>A pickled class instance based on a module in <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> in release 3.X won’t be unpickle-able in release 3.X+1, where the module won’t be in <code class="docutils literal notranslate"><span class="pre">__preview__</span></code>. Special code may be added to make this work, but this goes against the intent of this proposal, since it implies backward compatibility. Therefore, this PEP does not propose to preserve pickle compatibility.</p> </section> </section> <section id="credits"> <h2><a class="toc-backref" href="#credits" role="doc-backlink">Credits</a></h2> <p>Dj Gilcrease initially proposed the idea of having a <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> package in Python <a class="footnote-reference brackets" href="#id7" id="id5">[2]</a>. Although his original proposal uses the name <code class="docutils literal notranslate"><span class="pre">__experimental__</span></code>, we feel that <code class="docutils literal notranslate"><span class="pre">__preview__</span></code> conveys the meaning of this package in a better way.</p> </section> <section id="references"> <h2><a class="toc-backref" href="#references" role="doc-backlink">References</a></h2> <aside class="footnote-list brackets"> <aside class="footnote brackets" id="id6" role="doc-footnote"> <dt class="label" id="id6">[1]<em> (<a href='#id3'>1</a>, <a href='#id4'>2</a>) </em></dt> <dd>Discussed in this thread: <a class="reference external" href="https://mail.python.org/pipermail/python-ideas/2012-January/013246.html">https://mail.python.org/pipermail/python-ideas/2012-January/013246.html</a></aside> <aside class="footnote brackets" id="id7" role="doc-footnote"> <dt class="label" id="id7">[<a href="#id5">2</a>]</dt> <dd><a class="reference external" href="https://mail.python.org/pipermail/python-ideas/2011-August/011278.html">https://mail.python.org/pipermail/python-ideas/2011-August/011278.html</a></aside> <aside class="footnote brackets" id="id8" role="doc-footnote"> <dt class="label" id="id8">[<a href="#id1">3</a>]</dt> <dd>Guido’s decision: <a class="reference external" href="https://mail.python.org/pipermail/python-dev/2012-January/115962.html">https://mail.python.org/pipermail/python-dev/2012-January/115962.html</a></aside> <aside class="footnote brackets" id="id9" role="doc-footnote"> <dt class="label" id="id9">[<a href="#id2">4</a>]</dt> <dd>Proposal for inclusion of regex: <a class="reference external" href="http://bugs.python.org/issue2636">http://bugs.python.org/issue2636</a></aside> </aside> </section> <section id="copyright"> <h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2> <p>This document has been placed in the public domain.</p> </section> </section> <hr class="docutils" /> <p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0408.rst">https://github.com/python/peps/blob/main/peps/pep-0408.rst</a></p> <p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0408.rst">2025-02-01 08:59:27 GMT</a></p> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#pep-rejection">PEP Rejection</a></li> <li><a class="reference internal" href="#proposal-the-preview-package">Proposal - the __preview__ package</a><ul> <li><a class="reference internal" href="#which-modules-should-go-through-preview">Which modules should go through <code class="docutils literal notranslate"><span class="pre">__preview__</span></code></a></li> <li><a class="reference internal" href="#criteria-for-graduation">Criteria for “graduation”</a></li> <li><a class="reference internal" href="#example">Example</a></li> </ul> </li> <li><a class="reference internal" href="#rationale">Rationale</a><ul> <li><a class="reference internal" href="#benefits-for-the-core-development-team">Benefits for the core development team</a></li> <li><a class="reference internal" href="#benefits-for-end-users">Benefits for end users</a></li> </ul> </li> <li><a class="reference internal" href="#candidates-for-inclusion-into-preview">Candidates for inclusion into __preview__</a></li> <li><a class="reference internal" href="#relationship-with-pep-407">Relationship with PEP 407</a></li> <li><a class="reference internal" href="#rejected-alternatives-and-variations">Rejected alternatives and variations</a><ul> <li><a class="reference internal" href="#using-future">Using <code class="docutils literal notranslate"><span class="pre">__future__</span></code></a></li> <li><a class="reference internal" href="#versioning-the-package">Versioning the package</a></li> <li><a class="reference internal" href="#using-a-package-name-without-leading-and-trailing-underscores">Using a package name without leading and trailing underscores</a></li> <li><a class="reference internal" href="#preserving-pickle-compatibility">Preserving pickle compatibility</a></li> </ul> </li> <li><a class="reference internal" href="#credits">Credits</a></li> <li><a class="reference internal" href="#references">References</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> <br> <a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0408.rst">Page Source (GitHub)</a> </nav> </section> <script src="../_static/colour_scheme.js"></script> <script src="../_static/wrap_tables.js"></script> <script src="../_static/sticky_banner.js"></script> </body> </html>