python-peps/pep-3122/index.html

366 lines
30 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!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 3122 Delineation of the main module | peps.python.org</title>
<link rel="shortcut icon" href="../_static/py.png">
<link rel="canonical" href="https://peps.python.org/pep-3122/">
<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 3122 Delineation of the main module | peps.python.org'>
<meta property="og:description" content="Because of how name resolution works for relative imports in a world where PEP 328 is implemented, the ability to execute modules within a package ceases being possible. This failing stems from the fact that the module being executed as the “main” modu...">
<meta property="og:type" content="website">
<meta property="og:url" content="https://peps.python.org/pep-3122/">
<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="Because of how name resolution works for relative imports in a world where PEP 328 is implemented, the ability to execute modules within a package ceases being possible. This failing stems from the fact that the module being executed as the “main” modu...">
<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> &raquo; </li>
<li><a href="../pep-0000/">PEP Index</a> &raquo; </li>
<li>PEP 3122</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 3122 Delineation of the main module</h1>
<dl class="rfc2822 field-list simple">
<dt class="field-odd">Author<span class="colon">:</span></dt>
<dd class="field-odd">Brett Cannon</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">27-Apr-2007</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="#the-problem">The Problem</a></li>
<li><a class="reference internal" href="#the-solution">The Solution</a></li>
<li><a class="reference internal" href="#implementation">Implementation</a></li>
<li><a class="reference internal" href="#transition-plan">Transition Plan</a></li>
<li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul>
<li><a class="reference internal" href="#main-built-in"><code class="docutils literal notranslate"><span class="pre">__main__</span></code> built-in</a></li>
<li><a class="reference internal" href="#main-module-attribute"><code class="docutils literal notranslate"><span class="pre">__main__</span></code> module attribute</a></li>
<li><a class="reference internal" href="#use-file-instead-of-name">Use <code class="docutils literal notranslate"><span class="pre">__file__</span></code> instead of <code class="docutils literal notranslate"><span class="pre">__name__</span></code></a></li>
<li><a class="reference internal" href="#special-string-subclass-for-name-that-overrides-eq">Special string subclass for <code class="docutils literal notranslate"><span class="pre">__name__</span></code> that overrides <code class="docutils literal notranslate"><span class="pre">__eq__</span></code></a></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>
<div class="admonition attention">
<p class="admonition-title">Attention</p>
<p>This PEP has been rejected. Guido views running scripts within a
package as an anti-pattern <a class="footnote-reference brackets" href="#guido-rejection" id="id1">[3]</a>.</p>
</div>
<section id="abstract">
<h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2>
<p>Because of how name resolution works for relative imports in a world
where <a class="pep reference internal" href="../pep-0328/" title="PEP 328 Imports: Multi-Line and Absolute/Relative">PEP 328</a> is implemented, the ability to execute modules within a
package ceases being possible. This failing stems from the fact that
the module being executed as the “main” module replaces its
<code class="docutils literal notranslate"><span class="pre">__name__</span></code> attribute with <code class="docutils literal notranslate"><span class="pre">&quot;__main__&quot;</span></code> instead of leaving it as
the absolute name of the module. This breaks imports ability
to resolve relative imports from the main module into absolute names.</p>
<p>In order to resolve this issue, this PEP proposes to change how the
main module is delineated. By leaving the <code class="docutils literal notranslate"><span class="pre">__name__</span></code> attribute in
a module alone and setting <code class="docutils literal notranslate"><span class="pre">sys.main</span></code> to the name of the main
module this will allow at least some instances of executing a module
within a package that uses relative imports.</p>
<p>This PEP does not address the idea of introducing a module-level
function that is automatically executed like <a class="pep reference internal" href="../pep-0299/" title="PEP 299 Special __main__() function in modules">PEP 299</a> proposes.</p>
</section>
<section id="the-problem">
<h2><a class="toc-backref" href="#the-problem" role="doc-backlink">The Problem</a></h2>
<p>With the introduction of <a class="pep reference internal" href="../pep-0328/" title="PEP 328 Imports: Multi-Line and Absolute/Relative">PEP 328</a>, relative imports became dependent on
the <code class="docutils literal notranslate"><span class="pre">__name__</span></code> attribute of the module performing the import. This
is because the use of dots in a relative import are used to strip away
parts of the calling modules name to calculate where in the package
hierarchy an import should fall (prior to <a class="pep reference internal" href="../pep-0328/" title="PEP 328 Imports: Multi-Line and Absolute/Relative">PEP 328</a> relative
imports could fail and would fall back on absolute imports which had a
chance of succeeding).</p>
<p>For instance, consider the import <code class="docutils literal notranslate"><span class="pre">from</span> <span class="pre">..</span> <span class="pre">import</span> <span class="pre">spam</span></code> made from the
<code class="docutils literal notranslate"><span class="pre">bacon.ham.beans</span></code> module (<code class="docutils literal notranslate"><span class="pre">bacon.ham.beans</span></code> is not a package
itself, i.e., does not define <code class="docutils literal notranslate"><span class="pre">__path__</span></code>). Name resolution of the
relative import takes the callers name (<code class="docutils literal notranslate"><span class="pre">bacon.ham.beans</span></code>), splits
on dots, and then slices off the last n parts based on the level
(which is 2). In this example both <code class="docutils literal notranslate"><span class="pre">ham</span></code> and <code class="docutils literal notranslate"><span class="pre">beans</span></code> are dropped
and <code class="docutils literal notranslate"><span class="pre">spam</span></code> is joined with what is left (<code class="docutils literal notranslate"><span class="pre">bacon</span></code>). This leads to
the proper import of the module <code class="docutils literal notranslate"><span class="pre">bacon.spam</span></code>.</p>
<p>This reliance on the <code class="docutils literal notranslate"><span class="pre">__name__</span></code> attribute of a module when handling
relative imports becomes an issue when executing a script within a
package. Because the executing script has its name set to
<code class="docutils literal notranslate"><span class="pre">'__main__'</span></code>, import cannot resolve any relative imports, leading to
an <code class="docutils literal notranslate"><span class="pre">ImportError</span></code>.</p>
<p>For example, assume we have a package named <code class="docutils literal notranslate"><span class="pre">bacon</span></code> with an
<code class="docutils literal notranslate"><span class="pre">__init__.py</span></code> file containing:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span><span class="w"> </span><span class="nn">.</span><span class="w"> </span><span class="kn">import</span> <span class="n">spam</span>
</pre></div>
</div>
<p>Also create a module named <code class="docutils literal notranslate"><span class="pre">spam</span></code> within the <code class="docutils literal notranslate"><span class="pre">bacon</span></code> package (it
can be an empty file). Now if you try to execute the <code class="docutils literal notranslate"><span class="pre">bacon</span></code>
package (either through <code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">bacon/__init__.py</span></code> or
<code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">-m</span> <span class="pre">bacon</span></code>) you will get an <code class="docutils literal notranslate"><span class="pre">ImportError</span></code> about trying to
do a relative import from within a non-package. Obviously the import
is valid, but because of the setting of <code class="docutils literal notranslate"><span class="pre">__name__</span></code> to <code class="docutils literal notranslate"><span class="pre">'__main__'</span></code>
import thinks that <code class="docutils literal notranslate"><span class="pre">bacon/__init__.py</span></code> is not in a package since no
dots exist in <code class="docutils literal notranslate"><span class="pre">__name__</span></code>. To see how the algorithm works in more
detail, see <code class="docutils literal notranslate"><span class="pre">importlib.Import._resolve_name()</span></code> in the sandbox
<a class="footnote-reference brackets" href="#importlib" id="id2">[2]</a>.</p>
<p>Currently a work-around is to remove all relative imports in the
module being executed and make them absolute. This is unfortunate,
though, as one should not be required to use a specific type of
resource in order to make a module in a package be able to be
executed.</p>
</section>
<section id="the-solution">
<h2><a class="toc-backref" href="#the-solution" role="doc-backlink">The Solution</a></h2>
<p>The solution to the problem is to not change the value of <code class="docutils literal notranslate"><span class="pre">__name__</span></code>
in modules. But there still needs to be a way to let executing code
know it is being executed as a script. This is handled with a new
attribute in the <code class="docutils literal notranslate"><span class="pre">sys</span></code> module named <code class="docutils literal notranslate"><span class="pre">main</span></code>.</p>
<p>When a module is being executed as a script, <code class="docutils literal notranslate"><span class="pre">sys.main</span></code> will be set
to the name of the module. This changes the current idiom of:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="vm">__name__</span> <span class="o">==</span> <span class="s1">&#39;__main__&#39;</span><span class="p">:</span>
<span class="o">...</span>
</pre></div>
</div>
<p>to:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">import</span><span class="w"> </span><span class="nn">sys</span>
<span class="k">if</span> <span class="vm">__name__</span> <span class="o">==</span> <span class="n">sys</span><span class="o">.</span><span class="n">main</span><span class="p">:</span>
<span class="o">...</span>
</pre></div>
</div>
<p>The newly proposed solution does introduce an added line of
boilerplate which is a module import. But as the solution does not
introduce a new built-in or module attribute (as discussed in
<a class="reference internal" href="#rejected-ideas">Rejected Ideas</a>) it has been deemed worth the extra line.</p>
<p>Another issue with the proposed solution (which also applies to all
rejected ideas as well) is that it does not directly solve the problem
of discovering the name of a file. Consider <code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">bacon/spam.py</span></code>.
By the file name alone it is not obvious whether <code class="docutils literal notranslate"><span class="pre">bacon</span></code> is a
package. In order to properly find this out both the current
direction must exist on <code class="docutils literal notranslate"><span class="pre">sys.path</span></code> as well as <code class="docutils literal notranslate"><span class="pre">bacon/__init__.py</span></code>
existing.</p>
<p>But this is the simple example. Consider <code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">../spam.py</span></code>. From
the file name alone it is not at all clear if <code class="docutils literal notranslate"><span class="pre">spam.py</span></code> is in a
package or not. One possible solution is to find out what the
absolute name of <code class="docutils literal notranslate"><span class="pre">..</span></code>, check if a file named <code class="docutils literal notranslate"><span class="pre">__init__.py</span></code> exists,
and then look if the directory is on <code class="docutils literal notranslate"><span class="pre">sys.path</span></code>. If it is not, then
continue to walk up the directory until no more <code class="docutils literal notranslate"><span class="pre">__init__.py</span></code> files
are found or the directory is found on <code class="docutils literal notranslate"><span class="pre">sys.path</span></code>.</p>
<p>This could potentially be an expensive process. If the package depth
happens to be deep then it could require a large amount of disk access
to discover where the package is anchored on <code class="docutils literal notranslate"><span class="pre">sys.path</span></code>, if at all.
The stat calls alone can be expensive if the file system the executed
script is on is something like NFS.</p>
<p>Because of these issues, only when the <code class="docutils literal notranslate"><span class="pre">-m</span></code> command-line argument
(introduced by <a class="pep reference internal" href="../pep-0338/" title="PEP 338 Executing modules as scripts">PEP 338</a>) is used will <code class="docutils literal notranslate"><span class="pre">__name__</span></code> be set. Otherwise
the fallback semantics of setting <code class="docutils literal notranslate"><span class="pre">__name__</span></code> to <code class="docutils literal notranslate"><span class="pre">&quot;__main__&quot;</span></code> will
occur. <code class="docutils literal notranslate"><span class="pre">sys.main</span></code> will still be set to the proper value,
regardless of what <code class="docutils literal notranslate"><span class="pre">__name__</span></code> is set to.</p>
</section>
<section id="implementation">
<h2><a class="toc-backref" href="#implementation" role="doc-backlink">Implementation</a></h2>
<p>When the <code class="docutils literal notranslate"><span class="pre">-m</span></code> option is used, <code class="docutils literal notranslate"><span class="pre">sys.main</span></code> will be set to the
argument passed in. <code class="docutils literal notranslate"><span class="pre">sys.argv</span></code> will be adjusted as it is currently.
Then the equivalent of <code class="docutils literal notranslate"><span class="pre">__import__(self.main)</span></code> will occur. This
differs from current semantics as the <code class="docutils literal notranslate"><span class="pre">runpy</span></code> module fetches the
code object for the file specified by the module name in order to
explicitly set <code class="docutils literal notranslate"><span class="pre">__name__</span></code> and other attributes. This is no longer
needed as import can perform its normal operation in this situation.</p>
<p>If a file name is specified, then <code class="docutils literal notranslate"><span class="pre">sys.main</span></code> will be set to
<code class="docutils literal notranslate"><span class="pre">&quot;__main__&quot;</span></code>. The specified file will then be read and have a code
object created and then be executed with <code class="docutils literal notranslate"><span class="pre">__name__</span></code> set to
<code class="docutils literal notranslate"><span class="pre">&quot;__main__&quot;</span></code>. This mirrors current semantics.</p>
</section>
<section id="transition-plan">
<h2><a class="toc-backref" href="#transition-plan" role="doc-backlink">Transition Plan</a></h2>
<p>In order for Python 2.6 to be able to support both the current
semantics and the proposed semantics, <code class="docutils literal notranslate"><span class="pre">sys.main</span></code> will always be set
to <code class="docutils literal notranslate"><span class="pre">&quot;__main__&quot;</span></code>. Otherwise no change will occur for Python 2.6.
This unfortunately means that no benefit from this change will occur
in Python 2.6, but it maximizes compatibility for code that is to
work as much as possible with 2.6 and 3.0.</p>
<p>To help transition to the new idiom, 2to3 <a class="footnote-reference brackets" href="#to3" id="id3">[1]</a> will gain a rule to
transform the current <code class="docutils literal notranslate"><span class="pre">if</span> <span class="pre">__name__</span> <span class="pre">==</span> <span class="pre">'__main__':</span> <span class="pre">...</span></code> idiom to the
new one. This will not help with code that checks <code class="docutils literal notranslate"><span class="pre">__name__</span></code>
outside of the idiom, though.</p>
</section>
<section id="rejected-ideas">
<h2><a class="toc-backref" href="#rejected-ideas" role="doc-backlink">Rejected Ideas</a></h2>
<section id="main-built-in">
<h3><a class="toc-backref" href="#main-built-in" role="doc-backlink"><code class="docutils literal notranslate"><span class="pre">__main__</span></code> built-in</a></h3>
<p>A counter-proposal to introduce a built-in named <code class="docutils literal notranslate"><span class="pre">__main__</span></code>.
The value of the built-in would be the name of the module being
executed (just like the proposed <code class="docutils literal notranslate"><span class="pre">sys.main</span></code>). This would lead to a
new idiom of:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="vm">__name__</span> <span class="o">==</span> <span class="n">__main__</span><span class="p">:</span>
<span class="o">...</span>
</pre></div>
</div>
<p>A drawback is that the syntactic difference is subtle; the dropping
of quotes around “__main__”. Some believe that for existing Python
programmers bugs will be introduced where the quotation marks will be
put on by accident. But one could argue that the bug would be
discovered quickly through testing as it is a very shallow bug.</p>
<p>While the name of built-in could obviously be different (e.g.,
<code class="docutils literal notranslate"><span class="pre">main</span></code>) the other drawback is that it introduces a new built-in.
With a simple solution such as <code class="docutils literal notranslate"><span class="pre">sys.main</span></code> being possible without
adding another built-in to Python, this proposal was rejected.</p>
</section>
<section id="main-module-attribute">
<h3><a class="toc-backref" href="#main-module-attribute" role="doc-backlink"><code class="docutils literal notranslate"><span class="pre">__main__</span></code> module attribute</a></h3>
<p>Another proposal was to add a <code class="docutils literal notranslate"><span class="pre">__main__</span></code> attribute to every module.
For the one that was executing as the main module, the attribute would
have a true value while all other modules had a false value. This has
a nice consequence of simplify the main module idiom to:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="n">__main__</span><span class="p">:</span>
<span class="o">...</span>
</pre></div>
</div>
<p>The drawback was the introduction of a new module attribute. It also
required more integration with the import machinery than the proposed
solution.</p>
</section>
<section id="use-file-instead-of-name">
<h3><a class="toc-backref" href="#use-file-instead-of-name" role="doc-backlink">Use <code class="docutils literal notranslate"><span class="pre">__file__</span></code> instead of <code class="docutils literal notranslate"><span class="pre">__name__</span></code></a></h3>
<p>Any of the proposals could be changed to use the <code class="docutils literal notranslate"><span class="pre">__file__</span></code>
attribute on modules instead of <code class="docutils literal notranslate"><span class="pre">__name__</span></code>, including the current
semantics. The problem with this is that with the proposed solutions
there is the issue of modules having no <code class="docutils literal notranslate"><span class="pre">__file__</span></code> attribute defined
or having the same value as other modules.</p>
<p>The problem that comes up with the current semantics is you still have
to try to resolve the file path to a module name for the import to
work.</p>
</section>
<section id="special-string-subclass-for-name-that-overrides-eq">
<h3><a class="toc-backref" href="#special-string-subclass-for-name-that-overrides-eq" role="doc-backlink">Special string subclass for <code class="docutils literal notranslate"><span class="pre">__name__</span></code> that overrides <code class="docutils literal notranslate"><span class="pre">__eq__</span></code></a></h3>
<p>One proposal was to define a subclass of <code class="docutils literal notranslate"><span class="pre">str</span></code> that overrode the
<code class="docutils literal notranslate"><span class="pre">__eq__</span></code> method so that it would compare equal to <code class="docutils literal notranslate"><span class="pre">&quot;__main__&quot;</span></code> as
well as the actual name of the module. In all other respects the
subclass would be the same as <code class="docutils literal notranslate"><span class="pre">str</span></code>.</p>
<p>This was rejected as it seemed like too much of a hack.</p>
</section>
</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="to3" role="doc-footnote">
<dt class="label" id="to3">[<a href="#id3">1</a>]</dt>
<dd>2to3 tool
(<a class="reference external" href="http://svn.python.org/view/sandbox/trunk/2to3/">http://svn.python.org/view/sandbox/trunk/2to3/</a>) [ViewVC]</aside>
<aside class="footnote brackets" id="importlib" role="doc-footnote">
<dt class="label" id="importlib">[<a href="#id2">2</a>]</dt>
<dd>importlib
(<a class="reference external" href="http://svn.python.org/view/sandbox/trunk/import_in_py/importlib.py?view=markup">http://svn.python.org/view/sandbox/trunk/import_in_py/importlib.py?view=markup</a>)
[ViewVC]</aside>
<aside class="footnote brackets" id="guido-rejection" role="doc-footnote">
<dt class="label" id="guido-rejection">[<a href="#id1">3</a>]</dt>
<dd>Python-Dev email: “PEP to change how the main module is delineated”
(<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2007-April/006793.html">https://mail.python.org/pipermail/python-3000/2007-April/006793.html</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-3122.rst">https://github.com/python/peps/blob/main/peps/pep-3122.rst</a></p>
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-3122.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="#the-problem">The Problem</a></li>
<li><a class="reference internal" href="#the-solution">The Solution</a></li>
<li><a class="reference internal" href="#implementation">Implementation</a></li>
<li><a class="reference internal" href="#transition-plan">Transition Plan</a></li>
<li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul>
<li><a class="reference internal" href="#main-built-in"><code class="docutils literal notranslate"><span class="pre">__main__</span></code> built-in</a></li>
<li><a class="reference internal" href="#main-module-attribute"><code class="docutils literal notranslate"><span class="pre">__main__</span></code> module attribute</a></li>
<li><a class="reference internal" href="#use-file-instead-of-name">Use <code class="docutils literal notranslate"><span class="pre">__file__</span></code> instead of <code class="docutils literal notranslate"><span class="pre">__name__</span></code></a></li>
<li><a class="reference internal" href="#special-string-subclass-for-name-that-overrides-eq">Special string subclass for <code class="docutils literal notranslate"><span class="pre">__name__</span></code> that overrides <code class="docutils literal notranslate"><span class="pre">__eq__</span></code></a></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-3122.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>