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 423 – Naming conventions and recipes related to packaging | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0423/"> <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 423 – Naming conventions and recipes related to packaging | peps.python.org'> <meta property="og:description" content="This document deals with:"> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0423/"> <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="This document deals with:"> <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 423</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 423 – Naming conventions and recipes related to packaging</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author<span class="colon">:</span></dt> <dd class="field-odd">Benoit Bryon <benoit at marmelune.net></dd> <dt class="field-even">Discussions-To<span class="colon">:</span></dt> <dd class="field-even"><a class="reference external" href="https://mail.python.org/archives/list/distutils-sig@python.org/">Distutils-SIG list</a></dd> <dt class="field-odd">Status<span class="colon">:</span></dt> <dd class="field-odd"><abbr title="Inactive draft that may be taken up again at a later time">Deferred</abbr></dd> <dt class="field-even">Type<span class="colon">:</span></dt> <dd class="field-even"><abbr title="Non-normative PEP containing background, guidelines or other information relevant to the Python ecosystem">Informational</abbr></dd> <dt class="field-odd">Topic<span class="colon">:</span></dt> <dd class="field-odd"><a class="reference external" href="../topic/packaging/">Packaging</a></dd> <dt class="field-even">Created<span class="colon">:</span></dt> <dd class="field-even">24-May-2012</dd> <dt class="field-odd">Post-History<span class="colon">:</span></dt> <dd class="field-odd"><p></p></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-deferral">PEP Deferral</a></li> <li><a class="reference internal" href="#terminology">Terminology</a></li> <li><a class="reference internal" href="#relationship-with-other-peps">Relationship with other PEPs</a></li> <li><a class="reference internal" href="#overview">Overview</a></li> <li><a class="reference internal" href="#if-in-doubt-ask">If in doubt, ask</a></li> <li><a class="reference internal" href="#top-level-namespace-relates-to-code-ownership">Top-level namespace relates to code ownership</a><ul> <li><a class="reference internal" href="#respect-ownership">Respect ownership</a></li> <li><a class="reference internal" href="#private-including-closed-source-projects-use-a-namespace">Private (including closed-source) projects use a namespace</a></li> <li><a class="reference internal" href="#individual-projects-use-a-namespace">Individual projects use a namespace</a></li> <li><a class="reference internal" href="#community-owned-projects-can-avoid-namespace-packages">Community-owned projects can avoid namespace packages</a></li> <li><a class="reference internal" href="#in-doubt-use-an-individual-organization-namespace">In doubt, use an individual/organization namespace</a></li> </ul> </li> <li><a class="reference internal" href="#use-a-single-name">Use a single name</a><ul> <li><a class="reference internal" href="#multiple-packages-modules-should-be-rare">Multiple packages/modules should be rare</a></li> <li><a class="reference internal" href="#distinct-names-should-be-rare">Distinct names should be rare</a></li> </ul> </li> <li><a class="reference internal" href="#follow-pep-8-for-syntax-of-package-and-module-names">Follow PEP 8 for syntax of package and module names</a></li> <li><a class="reference internal" href="#pick-memorable-names">Pick memorable names</a></li> <li><a class="reference internal" href="#pick-meaningful-names">Pick meaningful names</a></li> <li><a class="reference internal" href="#use-packaging-metadata">Use packaging metadata</a></li> <li><a class="reference internal" href="#avoid-deep-nesting">Avoid deep nesting</a><ul> <li><a class="reference internal" href="#two-levels-is-almost-always-enough">Two levels is almost always enough</a></li> <li><a class="reference internal" href="#use-only-one-level-for-ownership">Use only one level for ownership</a></li> <li><a class="reference internal" href="#don-t-use-namespace-levels-for-categorization">Don’t use namespace levels for categorization</a></li> <li><a class="reference internal" href="#don-t-use-more-than-3-levels">Don’t use more than 3 levels</a></li> </ul> </li> <li><a class="reference internal" href="#conventions-for-communities-or-related-projects">Conventions for communities or related projects</a><ul> <li><a class="reference internal" href="#follow-community-or-related-project-conventions-if-any">Follow community or related project conventions, if any</a></li> <li><a class="reference internal" href="#use-standard-pattern-for-community-contributions">Use standard pattern for community contributions</a></li> <li><a class="reference internal" href="#organize-community-contributions">Organize community contributions</a></li> </ul> </li> <li><a class="reference internal" href="#register-names-with-pypi">Register names with PyPI</a></li> <li><a class="reference internal" href="#recipes">Recipes</a><ul> <li><a class="reference internal" href="#how-to-check-for-name-availability">How to check for name availability?</a></li> <li><a class="reference internal" href="#how-to-rename-a-project">How to rename a project?</a><ul> <li><a class="reference internal" href="#improved-handling-of-renamed-projects-on-pypi">Improved handling of renamed projects on PyPI</a></li> </ul> </li> <li><a class="reference internal" href="#how-to-apply-naming-guidelines-on-existing-projects">How to apply naming guidelines on existing projects?</a><ul> <li><a class="reference internal" href="#state-about-current-naming">State about current naming</a></li> <li><a class="reference internal" href="#promote-migrations">Promote migrations</a></li> <li><a class="reference internal" href="#opportunity">Opportunity</a></li> </ul> </li> </ul> </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>This document deals with:</p> <ul class="simple"> <li>names of Python projects,</li> <li>names of Python packages or modules being distributed,</li> <li>namespace packages.</li> </ul> <p>It provides guidelines and recipes for distribution authors:</p> <ul class="simple"> <li>new projects should follow the <a class="reference external" href="#overview">guidelines</a> below.</li> <li>existing projects should be aware of these guidelines and can follow <a class="reference external" href="#how-to-apply-naming-guidelines-on-existing-projects">specific recipes for existing projects</a>.</li> </ul> </section> <section id="pep-deferral"> <h2><a class="toc-backref" href="#pep-deferral" role="doc-backlink">PEP Deferral</a></h2> <p>Further consideration of this PEP has been deferred at least until after <a class="pep reference internal" href="../pep-0426/" title="PEP 426 – Metadata for Python Software Packages 2.0">PEP 426</a> (package metadata 2.0) and related updates have been resolved.</p> </section> <section id="terminology"> <h2><a class="toc-backref" href="#terminology" role="doc-backlink">Terminology</a></h2> <p>Reference is <a class="reference external" href="https://packaging.python.org/glossary/">packaging terminology in Python documentation</a>.</p> </section> <section id="relationship-with-other-peps"> <h2><a class="toc-backref" href="#relationship-with-other-peps" role="doc-backlink">Relationship with other PEPs</a></h2> <ul class="simple"> <li><a class="pep reference internal" href="../pep-0008/#package-and-module-names" title="PEP 8 – Style Guide for Python Code § Package and Module Names">PEP 8</a> deals with code style guide, including names of Python packages and modules. It covers syntax of package/modules names.</li> <li><a class="pep reference internal" href="../pep-0345/" title="PEP 345 – Metadata for Python Software Packages 1.2">PEP 345</a> deals with packaging metadata, and defines name argument of the <code class="docutils literal notranslate"><span class="pre">packaging.core.setup()</span></code> function.</li> <li><a class="pep reference internal" href="../pep-0420/" title="PEP 420 – Implicit Namespace Packages">PEP 420</a> deals with namespace packages. It brings support of namespace packages to Python core. Before, namespaces packages were implemented by external libraries.</li> <li><a class="pep reference internal" href="../pep-3108/" title="PEP 3108 – Standard Library Reorganization">PEP 3108</a> deals with transition between Python 2.x and Python 3.x applied to standard library: some modules to be deleted, some to be renamed. It points out that naming conventions matter and is an example of transition plan.</li> </ul> </section> <section id="overview"> <h2><a class="toc-backref" href="#overview" role="doc-backlink">Overview</a></h2> <p>Here is a summarized list of guidelines you should follow to choose names:</p> <ul class="simple"> <li><a class="reference external" href="#respect-ownership">understand and respect namespace ownership</a>.</li> <li>if your project is related to another project or community:<ul> <li>search for conventions in main project’s documentation, because <a class="reference external" href="#organize-community-contributions">projects should organize community contributions</a>.</li> <li><a class="reference external" href="#follow-community-or-related-project-conventions-if-any">follow specific project or related community conventions</a>, if any.</li> <li>if there is no convention, <a class="reference external" href="#use-standard-pattern-for-community-contributions">follow a standard naming pattern</a>.</li> </ul> </li> <li>make sure your project name is unique, i.e. avoid duplicates:<ul> <li><a class="reference external" href="#top-level-namespace-relates-to-code-ownership">use top-level namespace for ownership</a>,</li> <li><a class="reference external" href="#how-to-check-for-name-availability">check for name availability</a>,</li> <li><a class="reference internal" href="#register-names-with-pypi">register names with PyPI</a>.</li> </ul> </li> <li>make sure distributed packages and modules names are unique, unless you explicitly want to distribute alternatives to existing packages or modules. <a class="reference external" href="#use-a-single-name">Using the same value for package/module name and project name</a> is the recommended way to achieve this.</li> <li><a class="reference external" href="#multiple-packages-modules-should-be-rare">distribute only one package or module at a time</a>, unless you know what you are doing. It makes it possible to apply the “<a class="reference internal" href="#use-a-single-name">use a single name</a>” rule, and thus make names consistent.</li> <li>make it easy to discover and remember your project:<ul> <li><a class="reference external" href="#pick-memorable-names">use as much memorable names as possible</a>,</li> <li><a class="reference external" href="#pick-meaningful-names">use as much meaningful names as possible</a>,</li> <li><a class="reference external" href="#use-packaging-metadata">use other packaging metadata</a>.</li> </ul> </li> <li><a class="reference internal" href="#avoid-deep-nesting">avoid deep nesting</a>. Flat things are easier to use and remember than nested ones:<ul> <li>one or two namespace levels are recommended, because they are almost always enough.</li> <li>even if not recommended, three levels are, de facto, a common case.</li> <li>in most cases, you should not need more than three levels.</li> </ul> </li> <li><a class="reference external" href="#follow-pep-8-for-syntax-of-package-and-module-names">follow PEP 8</a> for syntax of package and module names.</li> <li>if you followed specific conventions, or if your project is intended to receive contributions from the community, <a class="reference internal" href="#organize-community-contributions">organize community contributions</a>.</li> <li><a class="reference external" href="#if-in-doubt-ask">if still in doubt, ask</a>.</li> </ul> </section> <section id="if-in-doubt-ask"> <h2><a class="toc-backref" href="#if-in-doubt-ask" role="doc-backlink">If in doubt, ask</a></h2> <p>If you feel unsure after reading this document, ask <a class="reference external" href="http://www.python.org/community/">Python community</a> on IRC or on a mailing list.</p> </section> <section id="top-level-namespace-relates-to-code-ownership"> <h2><a class="toc-backref" href="#top-level-namespace-relates-to-code-ownership" role="doc-backlink">Top-level namespace relates to code ownership</a></h2> <p>This helps avoid clashes between project names.</p> <p>Ownership could be:</p> <ul class="simple"> <li>an individual. Example: <a class="reference external" href="http://pypi.python.org/pypi/gp.fileupload/">gp.fileupload</a> is owned and maintained by Gael Pasgrimaud.</li> <li>an organization. Examples:<ul> <li><a class="reference external" href="http://pypi.python.org/pypi/zest.releaser/">zest.releaser</a> is owned and maintained by Zest Software.</li> <li><a class="reference external" href="http://djangoproject.com/">Django</a> is owned and maintained by the Django Software Foundation.</li> </ul> </li> <li>a group or community. Example: <a class="reference external" href="http://sphinx.pocoo.org">sphinx</a> is maintained by developers of the Sphinx project, not only by its author, Georg Brandl.</li> <li>a group or community related to another package. Example: <a class="reference external" href="http://pypi.python.org/pypi/collective.recaptcha/">collective.recaptcha</a> is owned by its author: David Glick, Groundwire. But the “collective” namespace is owned by Plone community.</li> </ul> <section id="respect-ownership"> <h3><a class="toc-backref" href="#respect-ownership" role="doc-backlink">Respect ownership</a></h3> <p>Understand the purpose of namespace before you use it.</p> <p>Don’t plug into a namespace you don’t own, unless explicitly authorized.</p> <p><a class="reference internal" href="#if-in-doubt-ask">If in doubt, ask</a>.</p> <p>As an example, don’t plug in “django.contrib” namespace because it is managed by Django’s core contributors.</p> <p>Exceptions can be defined by project authors. See <a class="reference internal" href="#organize-community-contributions">Organize community contributions</a> below.</p> <p>Also, this rule applies to non-Python projects.</p> <p>As an example, don’t use “apache” as top-level namespace: “Apache” is the name of an existing project (in the case of “Apache”, it is also a trademark).</p> </section> <section id="private-including-closed-source-projects-use-a-namespace"> <h3><a class="toc-backref" href="#private-including-closed-source-projects-use-a-namespace" role="doc-backlink">Private (including closed-source) projects use a namespace</a></h3> <p>… because private projects are owned by somebody. So apply the <a class="reference external" href="#top-level-namespace-relates-to-code-ownership">ownership rule</a>.</p> <p>For internal/customer projects, use your company name as the namespace.</p> <p>This rule applies to closed-source projects.</p> <p>As an example, if you are creating a “climbing” project for the “Python Sport” company: use “pythonsport.climbing” name, even if it is closed source.</p> </section> <section id="individual-projects-use-a-namespace"> <h3><a class="toc-backref" href="#individual-projects-use-a-namespace" role="doc-backlink">Individual projects use a namespace</a></h3> <p>… because they are owned by individuals. So apply the <a class="reference external" href="#top-level-namespace-relates-to-code-ownership">ownership rule</a>.</p> <p>There is no shame in releasing a project as open source even if it has an “internal” or “individual” name.</p> <p>If the project comes to a point where the author wants to change ownership (i.e. the project no longer belongs to an individual), keep in mind <a class="reference external" href="#how-to-rename-a-project">it is easy to rename the project</a>.</p> </section> <section id="community-owned-projects-can-avoid-namespace-packages"> <h3><a class="toc-backref" href="#community-owned-projects-can-avoid-namespace-packages" role="doc-backlink">Community-owned projects can avoid namespace packages</a></h3> <p>If your project is generic enough (i.e. it is not a contrib to another product or framework), you can avoid namespace packages. The base condition is generally that your project is owned by a group (i.e. the development team) which is dedicated to this project.</p> <p>Only use a “shared” namespace if you really intend the code to be community owned.</p> <p>As an example, <a class="reference external" href="http://sphinx.pocoo.org">sphinx</a> project belongs to the Sphinx development team. There is no need to have some “sphinx” namespace package with only one “sphinx.sphinx” project inside.</p> </section> <section id="in-doubt-use-an-individual-organization-namespace"> <h3><a class="toc-backref" href="#in-doubt-use-an-individual-organization-namespace" role="doc-backlink">In doubt, use an individual/organization namespace</a></h3> <p>If your project is really experimental, best choice is to use an individual or organization namespace:</p> <ul class="simple"> <li>it allows projects to be released early.</li> <li>it won’t block a name if the project is abandoned.</li> <li>it doesn’t block future changes. When a project becomes mature and there is no reason to keep individual ownership, <a class="reference external" href="#how-to-rename-a-project">it remains possible to rename the project</a>.</li> </ul> </section> </section> <section id="use-a-single-name"> <h2><a class="toc-backref" href="#use-a-single-name" role="doc-backlink">Use a single name</a></h2> <p>Distribute only one package (or only one module) per project, and use package (or module) name as project name.</p> <ul> <li>It avoids possible confusion between project name and distributed package or module name.</li> <li>It makes the name consistent.</li> <li>It is explicit: when one sees project name, he guesses package/module name, and vice versa.</li> <li>It also limits implicit clashes between package/module names. By using a single name, when you register a project name to <a class="reference external" href="http://pypi.python.org">PyPI</a>, you also perform a basic package/module name availability verification.<p>As an example, <a class="reference external" href="http://pypi.python.org/pypi/pipeline/">pipeline</a>, <a class="reference external" href="http://pypi.python.org/pypi/python-pipeline/">python-pipeline</a> and <a class="reference external" href="http://pypi.python.org/pypi/django-pipeline/">django-pipeline</a> all distribute a package or module called “pipeline”. So installing two of them leads to errors. This issue wouldn’t have occurred if these distributions used a single name.</p> </li> </ul> <p>Yes:</p> <ul class="simple"> <li>Package name: “kheops.pyramid”, i.e. <code class="docutils literal notranslate"><span class="pre">import</span> <span class="pre">kheops.pyramid</span></code></li> <li>Project name: “kheops.pyramid”, i.e. <code class="docutils literal notranslate"><span class="pre">pip</span> <span class="pre">install</span> <span class="pre">kheops.pyramid</span></code></li> </ul> <p>No:</p> <ul class="simple"> <li>Package name: “kheops”</li> <li>Project name: “KheopsPyramid”</li> </ul> <div class="admonition note"> <p class="admonition-title">Note</p> <p>For historical reasons, <a class="reference external" href="http://pypi.python.org">PyPI</a> contains many distributions where project and distributed package/module names differ.</p> </div> <section id="multiple-packages-modules-should-be-rare"> <h3><a class="toc-backref" href="#multiple-packages-modules-should-be-rare" role="doc-backlink">Multiple packages/modules should be rare</a></h3> <p>Technically, Python distributions can provide multiple packages and/or modules. See <a class="reference external" href="http://docs.python.org/dev/packaging/setupscript.html">setup script reference</a> for details.</p> <p>Some distributions actually do. As an example, <a class="reference external" href="http://pypi.python.org/pypi/setuptools">setuptools</a> and <a class="reference external" href="http://packages.python.org/distribute/">distribute</a> are both declaring “pkg_resources”, “easy_install” and “site” modules in addition to respective “setuptools” and “distribute” packages.</p> <p>Consider this use case as exceptional. In most cases, you don’t need this feature. So a distribution should provide only one package or module at a time.</p> </section> <section id="distinct-names-should-be-rare"> <h3><a class="toc-backref" href="#distinct-names-should-be-rare" role="doc-backlink">Distinct names should be rare</a></h3> <p>A notable exception to the <a class="reference internal" href="#use-a-single-name">Use a single name</a> rule is when you explicitly need distinct names.</p> <p>As an example, the <a class="reference external" href="http://pypi.python.org/pypi/Pillow/">Pillow</a> project provides an alternative to the original <a class="reference external" href="http://pypi.python.org/pypi/PIL/">PIL</a> distribution. Both projects distribute a “PIL” package.</p> <p>Consider this use case as exceptional. In most cases, you don’t need this feature. So a distributed package name should be equal to project name.</p> </section> </section> <section id="follow-pep-8-for-syntax-of-package-and-module-names"> <h2><a class="toc-backref" href="#follow-pep-8-for-syntax-of-package-and-module-names" role="doc-backlink">Follow PEP 8 for syntax of package and module names</a></h2> <p><a class="pep reference internal" href="../pep-0008/#package-and-module-names" title="PEP 8 – Style Guide for Python Code § Package and Module Names">PEP 8</a> applies to names of Python packages and modules.</p> <p>If you <a class="reference internal" href="#use-a-single-name">Use a single name</a>, <a class="pep reference internal" href="../pep-0008/#package-and-module-names" title="PEP 8 – Style Guide for Python Code § Package and Module Names">PEP 8</a> also applies to project names. The exceptions are namespace packages, where dots are required in project name.</p> </section> <section id="pick-memorable-names"> <h2><a class="toc-backref" href="#pick-memorable-names" role="doc-backlink">Pick memorable names</a></h2> <p>One important thing about a project name is that it be memorable.</p> <p>As an example, <a class="reference external" href="http://pypi.python.org/pypi/celery/">celery</a> is not a meaningful name. At first, it is not obvious that it deals with message queuing. But it is memorable, partly because it can be used to feed a <a class="reference external" href="http://www.rabbitmq.com">RabbitMQ</a> server.</p> </section> <section id="pick-meaningful-names"> <h2><a class="toc-backref" href="#pick-meaningful-names" role="doc-backlink">Pick meaningful names</a></h2> <p>Ask yourself “how would I describe in one sentence what this name is for?”, and then “could anyone have guessed that by looking at the name?”.</p> <p>As an example, <a class="reference external" href="http://pypi.python.org/pypi/DateUtils/">DateUtils</a> is a meaningful name. It is obvious that it deals with utilities for dates.</p> <p>When you are using namespaces, try to make each part meaningful.</p> </section> <section id="use-packaging-metadata"> <h2><a class="toc-backref" href="#use-packaging-metadata" role="doc-backlink">Use packaging metadata</a></h2> <p>Consider project names as unique identifiers on PyPI:</p> <ul class="simple"> <li>it is important that these identifiers remain human-readable.</li> <li>it is even better when these identifiers are meaningful.</li> <li>but the primary purpose of identifiers is not to classify or describe projects.</li> </ul> <p><strong>Classifiers and keywords metadata are made for categorization of distributions.</strong> Summary and description metadata are meant to describe the project.</p> <p>As an example, there is a “<a class="reference external" href="http://pypi.python.org/pypi?:action=browse&show=all&c=525">Framework :: Twisted</a>” classifier. Even if names are quite heterogeneous (they don’t follow a particular pattern), we get the list.</p> <p>In order to <a class="reference internal" href="#organize-community-contributions">Organize community contributions</a>, conventions about names and namespaces matter, but conventions about metadata should be even more important.</p> <p>As an example, we can find Plone portlets in many places:</p> <ul class="simple"> <li>plone.portlet.*</li> <li>collective.portlet.*</li> <li>collective.portlets.*</li> <li>collective.*.portlets</li> <li>some vendor-related projects such as “quintagroup.portlet.cumulus”</li> <li>and even projects where “portlet” pattern doesn’t appear in the name.</li> </ul> <p>Even if Plone community has conventions, using the name to categorize distributions is inappropriate. It’s impossible to get the full list of distributions that provide portlets for Plone by filtering on names. But it would be possible if all these distributions used “Framework :: Plone” classifier and “portlet” keyword.</p> </section> <section id="avoid-deep-nesting"> <h2><a class="toc-backref" href="#avoid-deep-nesting" role="doc-backlink">Avoid deep nesting</a></h2> <p><a class="pep reference internal" href="../pep-0020/" title="PEP 20 – The Zen of Python">The Zen of Python</a> says “Flat is better than nested”.</p> <section id="two-levels-is-almost-always-enough"> <h3><a class="toc-backref" href="#two-levels-is-almost-always-enough" role="doc-backlink">Two levels is almost always enough</a></h3> <p>Don’t define everything in deeply nested hierarchies: you will end up with projects and packages like “pythonsport.common.maps.forest”. This type of name is both verbose and cumbersome (e.g. if you have many imports from the package).</p> <p>Furthermore, big hierarchies tend to break down over time as the boundaries between different packages blur.</p> <p>The consensus is that two levels of nesting are preferred.</p> <p>For example, we have <code class="docutils literal notranslate"><span class="pre">plone.principalsource</span></code> instead of <code class="docutils literal notranslate"><span class="pre">plone.source.principal</span></code> or something like that. The name is shorter, the package structure is simpler, and there would be very little to gain from having three levels of nesting here. It would be impractical to try to put all “core Plone” sources (a source is kind of vocabulary) into the <code class="docutils literal notranslate"><span class="pre">plone.source.*</span></code> namespace, in part because some sources are part of other packages, and in part because sources already exist in other places. Had we made a new namespace, it would be inconsistently used from the start.</p> <p>Yes: “pyranha”</p> <p>Yes: “pythonsport.climbing”</p> <p>Yes: “pythonsport.forestmap”</p> <p>No: “pythonsport.maps.forest”</p> </section> <section id="use-only-one-level-for-ownership"> <h3><a class="toc-backref" href="#use-only-one-level-for-ownership" role="doc-backlink">Use only one level for ownership</a></h3> <p>Don’t use 3 levels to set individual/organization ownership in a community namespace.</p> <p>As an example, let’s consider:</p> <ul class="simple"> <li>you are plugging into a community namespace, such as “collective”.</li> <li>and you want to add a more restrictive “ownership” level, to avoid clashes inside the community.</li> </ul> <p>In such a case, <strong>you’d better use the most restrictive ownership level as first level.</strong></p> <p>As an example, where “collective” is a major community namespace that “gergovie” belongs to, and “vercingetorix” it the name of “gergovie” author:</p> <p>No: “collective.vercingetorix.gergovie”</p> <p>Yes: “vercingetorix.gergovie”</p> </section> <section id="don-t-use-namespace-levels-for-categorization"> <h3><a class="toc-backref" href="#don-t-use-namespace-levels-for-categorization" role="doc-backlink">Don’t use namespace levels for categorization</a></h3> <p><a class="reference internal" href="#use-packaging-metadata">Use packaging metadata</a> instead.</p> </section> <section id="don-t-use-more-than-3-levels"> <h3><a class="toc-backref" href="#don-t-use-more-than-3-levels" role="doc-backlink">Don’t use more than 3 levels</a></h3> <p>Technically, you can create deeply nested hierarchies. However, in most cases, you shouldn’t need it.</p> <div class="admonition note"> <p class="admonition-title">Note</p> <p>Even communities where namespaces are standard don’t use more than 3 levels.</p> </div> </section> </section> <section id="conventions-for-communities-or-related-projects"> <h2><a class="toc-backref" href="#conventions-for-communities-or-related-projects" role="doc-backlink">Conventions for communities or related projects</a></h2> <section id="follow-community-or-related-project-conventions-if-any"> <h3><a class="toc-backref" href="#follow-community-or-related-project-conventions-if-any" role="doc-backlink">Follow community or related project conventions, if any</a></h3> <p>Projects or related communities can have specific conventions, which may differ from those explained in this document.</p> <p>In such a case, <a class="reference external" href="#organize-community-contributions">they should declare specific conventions in documentation</a>.</p> <p>So, if your project belongs to another project or to a community, first look for specific conventions in main project’s documentation.</p> <p>If there is no specific conventions, follow the ones declared in this document.</p> <p>As an example, <a class="reference external" href="http://plone.org/community/develop">Plone community</a> releases community contributions in the “collective” namespace package. It differs from the <a class="reference external" href="#use-standard-pattern-for-community-contributions">standard namespace for contributions</a> proposed here. But since it is documented, there is no ambiguity and you should follow this specific convention.</p> </section> <section id="use-standard-pattern-for-community-contributions"> <h3><a class="toc-backref" href="#use-standard-pattern-for-community-contributions" role="doc-backlink">Use standard pattern for community contributions</a></h3> <p>When no specific rule is defined, use the <code class="docutils literal notranslate"><span class="pre">${MAINPROJECT}contrib.${PROJECT}</span></code> pattern to store community contributions for any product or framework, where:</p> <ul class="simple"> <li><code class="docutils literal notranslate"><span class="pre">${MAINPROJECT}</span></code> is the name of the related project. “pyranha” in the example below.</li> <li><code class="docutils literal notranslate"><span class="pre">${PROJECT}</span></code> is the name of your project. “giantteeth” in the example below.</li> </ul> <p>As an example:</p> <ul class="simple"> <li>you are the author of “pyranha” project. You own the “pyranha” namespace.</li> <li>you didn’t defined specific naming conventions for community contributions.</li> <li>a third-party developer wants to publish a “giantteeth” project related to your “pyranha” project in a community namespace. So he should publish it as “pyranhacontrib.giantteeth”.</li> </ul> <p>It is the simplest way to <a class="reference internal" href="#organize-community-contributions">Organize community contributions</a>.</p> <div class="admonition note"> <p class="admonition-title">Note</p> <p>Why <code class="docutils literal notranslate"><span class="pre">${MAINPROJECT}contrib.*</span></code> pattern?</p> <ul class="simple"> <li><code class="docutils literal notranslate"><span class="pre">${MAINPROJECT}c.*</span></code> is not explicit enough. As examples, “zc” belongs to “Zope Corporation” whereas “z3c” belongs to “Zope 3 community”.</li> <li><code class="docutils literal notranslate"><span class="pre">${MAINPROJECT}community</span></code> is too long.</li> <li><code class="docutils literal notranslate"><span class="pre">${MAINPROJECT}community</span></code> conflicts with existing namespaces such as “iccommunity” or “PyCommunity”.</li> <li><code class="docutils literal notranslate"><span class="pre">${MAINPROJECT}.contrib.*</span></code> is inside ${MAINPROJECT} namespace, i.e. it is owned by ${MAINPROJECT} authors. It breaks the <a class="reference internal" href="#top-level-namespace-relates-to-code-ownership">Top-level namespace relates to code ownership</a> rule.</li> <li><code class="docutils literal notranslate"><span class="pre">${MAINPROJECT}.contrib.*</span></code> breaks the <a class="reference internal" href="#avoid-deep-nesting">Avoid deep nesting</a> rule.</li> <li>names where <code class="docutils literal notranslate"><span class="pre">${MAINPROJECT}</span></code> doesn’t appear are not explicit enough, i.e. nobody can guess they are related to <code class="docutils literal notranslate"><span class="pre">${MAINPROJECT}</span></code>. As an example, it is not obvious that “collective.*” belongs to Plone community.</li> <li><code class="docutils literal notranslate"><span class="pre">{$DIST}contrib.*</span></code> looks like existing <code class="docutils literal notranslate"><span class="pre">sphinxcontrib-*</span></code> packages. But <code class="docutils literal notranslate"><span class="pre">sphinxcontrib-*</span></code> is actually about Sphinx contrib, so this is not a real conflict… In fact, the “contrib” suffix was inspired by “sphinxcontrib”.</li> </ul> </div> </section> <section id="organize-community-contributions"> <h3><a class="toc-backref" href="#organize-community-contributions" role="doc-backlink">Organize community contributions</a></h3> <p>This is the counterpart of the <a class="reference external" href="#follow-community-or-related-project-conventions-if-any">follow community conventions</a> and <a class="reference external" href="#use-standard-pattern-for-community-contributions">standard pattern for contributions</a> rules.</p> <p>Actions:</p> <ul class="simple"> <li>Choose a naming convention for community contributions.</li> <li>If it is not <a class="reference external" href="#use-standard-pattern-for-community-contributions">the default</a>, then document it.<ul> <li>if you use the <a class="reference external" href="#use-standard-pattern-for-community-contributions">default convention</a>, then this document should be enough. Don’t repeat it. You may reference it.</li> <li>else, tell users about custom conventions in project’s “contribute” or “create modules” documentation.</li> </ul> </li> <li>Also recommend the use of additional metadata, such as <a class="reference external" href="#use-packaging-metadata">classifiers and keywords</a>.</li> </ul> <p>About convention choices:</p> <ul> <li>New projects should choose the <a class="reference external" href="#use-standard-pattern-for-community-contributions">default contrib pattern</a>.</li> <li>Existing projects with community contributions should start with custom conventions. Then they can <a class="reference internal" href="#promote-migrations">Promote migrations</a>.<p>It means that existing community conventions don’t have to be changed. But, at least, they should be explicitly documented.</p> </li> </ul> <p>Example: “pyranha” is your project name and package name. Tell contributors that:</p> <ul class="simple"> <li>pyranha-related distributions should use the “pyranha” keyword</li> <li>pyranha-related distributions providing templates should also use “templates” keyword.</li> <li>community contributions should be released under “pyranhacontrib” namespace (i.e. use “pyranhacontrib.*” pattern).</li> </ul> </section> </section> <section id="register-names-with-pypi"> <h2><a class="toc-backref" href="#register-names-with-pypi" role="doc-backlink">Register names with PyPI</a></h2> <p><a class="reference external" href="http://pypi.python.org">PyPI</a> is the central place for distributions in Python community. So, it is also the place where to register project and package names.</p> <p>See <a class="reference external" href="https://docs.python.org/3/distutils/packageindex.html">Registering with the Package Index</a> for details.</p> </section> <section id="recipes"> <h2><a class="toc-backref" href="#recipes" role="doc-backlink">Recipes</a></h2> <p>The following recipes will help you follow the guidelines and conventions above.</p> <section id="how-to-check-for-name-availability"> <h3><a class="toc-backref" href="#how-to-check-for-name-availability" role="doc-backlink">How to check for name availability?</a></h3> <p>Before you choose a project name, make sure it hasn’t already been registered in the following locations:</p> <ul class="simple"> <li><a class="reference external" href="http://pypi.python.org">PyPI</a></li> <li>that’s all. PyPI is the only official place.</li> </ul> <p>As an example, you could also check in various locations such as popular code hosting services, but keep in mind that PyPI is the only place you can <strong>register</strong> for names in Python community.</p> <p>That’s why it is important you <a class="reference internal" href="#register-names-with-pypi">register names with PyPI</a>.</p> <p>Also make sure the names of distributed packages or modules haven’t already been registered:</p> <ul class="simple"> <li>in the <a class="reference external" href="http://docs.python.org/library/index.html">Python Standard Library</a>.</li> <li>inside projects at <code class="docutils literal notranslate"><span class="pre">PyPI</span></code>. There is currently no helper for that. Notice that the more projects follow the <a class="reference internal" href="#use-a-single-name">use a single name</a> rule, the easier is the verification.</li> <li>you may <a class="reference external" href="#if-in-doubt-ask">ask the community</a>.</li> </ul> <p>The <a class="reference internal" href="#use-a-single-name">use a single name</a> rule also helps you avoid clashes with package names: if a project name is available, then the package name has good chances to be available too.</p> </section> <section id="how-to-rename-a-project"> <h3><a class="toc-backref" href="#how-to-rename-a-project" role="doc-backlink">How to rename a project?</a></h3> <p>Renaming a project is possible, but keep in mind that it will cause some confusions. So, pay particular attention to README and documentation, so that users understand what happened.</p> <ol class="arabic simple"> <li>First of all, <strong>do not remove legacy distributions from PyPI</strong>. Because some users may be using them.</li> <li>Copy the legacy project, then change names (project and package/module). Pay attention to, at least:<ul class="simple"> <li>packaging files,</li> <li>folder name that contains source files,</li> <li>documentation, including README,</li> <li>import statements in code.</li> </ul> </li> <li>Assign <code class="docutils literal notranslate"><span class="pre">Obsoletes-Dist</span></code> metadata to new distribution in setup.cfg file. See <a class="pep reference internal" href="../pep-0345/#obsoletes-dist-multiple-use" title="PEP 345 – Metadata for Python Software Packages 1.2 § Obsoletes-Dist (multiple use)">PEP 345 about Obsolete-Dist</a> and <a class="reference external" href="http://docs.python.org/dev/packaging/setupcfg.html">setup.cfg specification</a>.</li> <li>Release a new version of the renamed project, then publish it.</li> <li>Edit legacy project:<ul class="simple"> <li>add dependency to new project,</li> <li>drop everything except packaging stuff,</li> <li>add the <code class="docutils literal notranslate"><span class="pre">Development</span> <span class="pre">Status</span> <span class="pre">::</span> <span class="pre">7</span> <span class="pre">-</span> <span class="pre">Inactive</span></code> classifier in setup script,</li> <li>publish a new release.</li> </ul> </li> </ol> <p>So, users of the legacy package:</p> <ul class="simple"> <li>can continue using the legacy distributions at a deprecated version,</li> <li>can upgrade to last version of legacy distribution, which is empty…</li> <li>… and automatically download new distribution as a dependency of the legacy one.</li> </ul> <p>Users who discover the legacy project see it is inactive.</p> <section id="improved-handling-of-renamed-projects-on-pypi"> <h4><a class="toc-backref" href="#improved-handling-of-renamed-projects-on-pypi" role="doc-backlink">Improved handling of renamed projects on PyPI</a></h4> <p>If many projects follow <a class="reference external" href="#how-to-rename-a-project">Renaming howto</a> recipe, then many legacy distributions will have the following characteristics:</p> <ul class="simple"> <li><code class="docutils literal notranslate"><span class="pre">Development</span> <span class="pre">Status</span> <span class="pre">::</span> <span class="pre">7</span> <span class="pre">-</span> <span class="pre">Inactive</span></code> classifier.</li> <li>latest version is empty, except packaging stuff.</li> <li>latest version “redirects” to another distribution. E.g. it has a single dependency on the renamed project.</li> <li>referenced as <code class="docutils literal notranslate"><span class="pre">Obsoletes-Dist</span></code> in a newer distribution.</li> </ul> <p>So it will be possible to detect renamed projects and improve readability on PyPI. So that users can focus on active distributions. But this feature is not required now. There is no urge. It won’t be covered in this document.</p> </section> </section> <section id="how-to-apply-naming-guidelines-on-existing-projects"> <h3><a class="toc-backref" href="#how-to-apply-naming-guidelines-on-existing-projects" role="doc-backlink">How to apply naming guidelines on existing projects?</a></h3> <p><strong>There is no obligation for existing projects to be renamed</strong>. The choice is left to project authors and mainteners for obvious reasons.</p> <p>However, project authors are invited to:</p> <ul class="simple"> <li>at least, <a class="reference internal" href="#state-about-current-naming">state about current naming</a>.</li> <li>then <a class="reference external" href="#promote-migrations">plan and promote migration</a>.</li> <li>optionally actually <a class="reference external" href="#how-to-rename-a-project">rename existing project or distributed packages/modules</a>.</li> </ul> <section id="state-about-current-naming"> <h4><a class="toc-backref" href="#state-about-current-naming" role="doc-backlink">State about current naming</a></h4> <p>The important thing, at first, is that you state about current choices:</p> <ul class="simple"> <li>Ask yourself “why did I choose the current name?”, then document it.</li> <li>If there are differences with the guidelines provided in this document, you should tell your users.</li> <li>If possible, create issues in the project’s bugtracker, at least for record. Then you are free to resolve them later, or maybe mark them as “wontfix”.</li> </ul> <p>Projects that are meant to receive contributions from community should also <a class="reference internal" href="#organize-community-contributions">organize community contributions</a>.</p> </section> <section id="promote-migrations"> <h4><a class="toc-backref" href="#promote-migrations" role="doc-backlink">Promote migrations</a></h4> <p>Every Python developer should migrate whenever possible, or promote the migrations in their respective communities.</p> <p>Apply these guidelines on your projects, then the community will see it is safe.</p> <p>In particular, “leaders” such as authors of popular projects are influential, they have power and, thus, responsibility over communities.</p> <p>Apply these guidelines on popular projects, then communities will adopt the conventions too.</p> <p><strong>Projects should promote migrations when they release a new (major) version</strong>, particularly <a class="reference external" href="#opportunity">if this version introduces support for Python 3.x, new standard library’s packaging or namespace packages</a>.</p> </section> <section id="opportunity"> <h4><a class="toc-backref" href="#opportunity" role="doc-backlink">Opportunity</a></h4> <p>As of Python 3.3 being developed:</p> <ul class="simple"> <li>many projects are not Python 3.x compatible. It includes “big” products or frameworks. It means that many projects will have to do a migration to support Python 3.x.</li> <li>packaging (aka distutils2) is on the starting blocks. When it is released, projects will be invited to migrate and use new packaging.</li> <li><a class="pep reference internal" href="../pep-0420/" title="PEP 420 – Implicit Namespace Packages">PEP 420</a> brings official support of namespace packages to Python.</li> </ul> <p>It means that most active projects should be about to migrate in the next year(s) to support Python 3.x, new packaging or new namespace packages.</p> <p>Such an opportunity is unique and won’t come again soon! So let’s introduce and promote naming conventions as soon as possible (i.e. <strong>now</strong>).</p> </section> </section> </section> <section id="references"> <h2><a class="toc-backref" href="#references" role="doc-backlink">References</a></h2> <p>Additional background:</p> <ul class="simple"> <li><a class="reference external" href="http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and-namespaces">Martin Aspeli’s article about names</a>. Some parts of this document are quotes from this article.</li> <li><a class="reference external" href="http://docs.python.org/dev/packaging/">in development official packaging documentation</a>.</li> <li><a class="reference external" href="http://guide.python-distribute.org/specification.html#naming-specification">The Hitchhiker’s Guide to Packaging</a>, which has an empty placeholder for “naming specification”.</li> </ul> <p>References and footnotes:</p> </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-0423.rst">https://github.com/python/peps/blob/main/peps/pep-0423.rst</a></p> <p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0423.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-deferral">PEP Deferral</a></li> <li><a class="reference internal" href="#terminology">Terminology</a></li> <li><a class="reference internal" href="#relationship-with-other-peps">Relationship with other PEPs</a></li> <li><a class="reference internal" href="#overview">Overview</a></li> <li><a class="reference internal" href="#if-in-doubt-ask">If in doubt, ask</a></li> <li><a class="reference internal" href="#top-level-namespace-relates-to-code-ownership">Top-level namespace relates to code ownership</a><ul> <li><a class="reference internal" href="#respect-ownership">Respect ownership</a></li> <li><a class="reference internal" href="#private-including-closed-source-projects-use-a-namespace">Private (including closed-source) projects use a namespace</a></li> <li><a class="reference internal" href="#individual-projects-use-a-namespace">Individual projects use a namespace</a></li> <li><a class="reference internal" href="#community-owned-projects-can-avoid-namespace-packages">Community-owned projects can avoid namespace packages</a></li> <li><a class="reference internal" href="#in-doubt-use-an-individual-organization-namespace">In doubt, use an individual/organization namespace</a></li> </ul> </li> <li><a class="reference internal" href="#use-a-single-name">Use a single name</a><ul> <li><a class="reference internal" href="#multiple-packages-modules-should-be-rare">Multiple packages/modules should be rare</a></li> <li><a class="reference internal" href="#distinct-names-should-be-rare">Distinct names should be rare</a></li> </ul> </li> <li><a class="reference internal" href="#follow-pep-8-for-syntax-of-package-and-module-names">Follow PEP 8 for syntax of package and module names</a></li> <li><a class="reference internal" href="#pick-memorable-names">Pick memorable names</a></li> <li><a class="reference internal" href="#pick-meaningful-names">Pick meaningful names</a></li> <li><a class="reference internal" href="#use-packaging-metadata">Use packaging metadata</a></li> <li><a class="reference internal" href="#avoid-deep-nesting">Avoid deep nesting</a><ul> <li><a class="reference internal" href="#two-levels-is-almost-always-enough">Two levels is almost always enough</a></li> <li><a class="reference internal" href="#use-only-one-level-for-ownership">Use only one level for ownership</a></li> <li><a class="reference internal" href="#don-t-use-namespace-levels-for-categorization">Don’t use namespace levels for categorization</a></li> <li><a class="reference internal" href="#don-t-use-more-than-3-levels">Don’t use more than 3 levels</a></li> </ul> </li> <li><a class="reference internal" href="#conventions-for-communities-or-related-projects">Conventions for communities or related projects</a><ul> <li><a class="reference internal" href="#follow-community-or-related-project-conventions-if-any">Follow community or related project conventions, if any</a></li> <li><a class="reference internal" href="#use-standard-pattern-for-community-contributions">Use standard pattern for community contributions</a></li> <li><a class="reference internal" href="#organize-community-contributions">Organize community contributions</a></li> </ul> </li> <li><a class="reference internal" href="#register-names-with-pypi">Register names with PyPI</a></li> <li><a class="reference internal" href="#recipes">Recipes</a><ul> <li><a class="reference internal" href="#how-to-check-for-name-availability">How to check for name availability?</a></li> <li><a class="reference internal" href="#how-to-rename-a-project">How to rename a project?</a><ul> <li><a class="reference internal" href="#improved-handling-of-renamed-projects-on-pypi">Improved handling of renamed projects on PyPI</a></li> </ul> </li> <li><a class="reference internal" href="#how-to-apply-naming-guidelines-on-existing-projects">How to apply naming guidelines on existing projects?</a><ul> <li><a class="reference internal" href="#state-about-current-naming">State about current naming</a></li> <li><a class="reference internal" href="#promote-migrations">Promote migrations</a></li> <li><a class="reference internal" href="#opportunity">Opportunity</a></li> </ul> </li> </ul> </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-0423.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>