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 3113 – Removal of Tuple Parameter Unpacking | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-3113/"> <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 3113 – Removal of Tuple Parameter Unpacking | peps.python.org'> <meta property="og:description" content="Tuple parameter unpacking is the use of a tuple as a parameter in a function signature so as to have a sequence argument automatically unpacked. An example is:"> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-3113/"> <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="Tuple parameter unpacking is the use of a tuple as a parameter in a function signature so as to have a sequence argument automatically unpacked. An example is:"> <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 3113</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 3113 – Removal of Tuple Parameter Unpacking</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author<span class="colon">:</span></dt> <dd class="field-odd">Brett Cannon <brett at python.org></dd> <dt class="field-even">Status<span class="colon">:</span></dt> <dd class="field-even"><abbr title="Accepted and implementation complete, or no longer active">Final</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">02-Mar-2007</dd> <dt class="field-odd">Python-Version<span class="colon">:</span></dt> <dd class="field-odd">3.0</dd> <dt class="field-even">Post-History<span class="colon">:</span></dt> <dd class="field-even"><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="#why-they-should-go">Why They Should Go</a><ul> <li><a class="reference internal" href="#introspection-issues">Introspection Issues</a></li> <li><a class="reference internal" href="#no-loss-of-abilities-if-removed">No Loss of Abilities If Removed</a></li> <li><a class="reference internal" href="#exception-to-the-rule">Exception To The Rule</a></li> <li><a class="reference internal" href="#uninformative-error-messages">Uninformative Error Messages</a></li> <li><a class="reference internal" href="#little-usage">Little Usage</a></li> </ul> </li> <li><a class="reference internal" href="#why-they-should-supposedly-stay">Why They Should (Supposedly) Stay</a><ul> <li><a class="reference internal" href="#practical-use">Practical Use</a></li> <li><a class="reference internal" href="#self-documentation-for-parameters">Self-Documentation For Parameters</a></li> </ul> </li> <li><a class="reference internal" href="#transition-plan">Transition Plan</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>Tuple parameter unpacking is the use of a tuple as a parameter in a function signature so as to have a sequence argument automatically unpacked. An example is:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">fxn</span><span class="p">(</span><span class="n">a</span><span class="p">,</span> <span class="p">(</span><span class="n">b</span><span class="p">,</span> <span class="n">c</span><span class="p">),</span> <span class="n">d</span><span class="p">):</span> <span class="k">pass</span> </pre></div> </div> <p>The use of <code class="docutils literal notranslate"><span class="pre">(b,</span> <span class="pre">c)</span></code> in the signature requires that the second argument to the function be a sequence of length two (e.g., <code class="docutils literal notranslate"><span class="pre">[42,</span> <span class="pre">-13]</span></code>). When such a sequence is passed it is unpacked and has its values assigned to the parameters, just as if the statement <code class="docutils literal notranslate"><span class="pre">b,</span> <span class="pre">c</span> <span class="pre">=</span> <span class="pre">[42,</span> <span class="pre">-13]</span></code> had been executed in the parameter.</p> <p>Unfortunately this feature of Python’s rich function signature abilities, while handy in some situations, causes more issues than they are worth. Thus this PEP proposes their removal from the language in Python 3.0.</p> </section> <section id="why-they-should-go"> <h2><a class="toc-backref" href="#why-they-should-go" role="doc-backlink">Why They Should Go</a></h2> <section id="introspection-issues"> <h3><a class="toc-backref" href="#introspection-issues" role="doc-backlink">Introspection Issues</a></h3> <p>Python has very powerful introspection capabilities. These extend to function signatures. There are no hidden details as to what a function’s call signature is. In general it is fairly easy to figure out various details about a function’s signature by viewing the function object and various attributes on it (including the function’s <code class="docutils literal notranslate"><span class="pre">func_code</span></code> attribute).</p> <p>But there is great difficulty when it comes to tuple parameters. The existence of a tuple parameter is denoted by its name being made of a <code class="docutils literal notranslate"><span class="pre">.</span></code> and a number in the <code class="docutils literal notranslate"><span class="pre">co_varnames</span></code> attribute of the function’s code object. This allows the tuple argument to be bound to a name that only the bytecode is aware of and cannot be typed in Python source. But this does not specify the format of the tuple: its length, whether there are nested tuples, etc.</p> <p>In order to get all of the details about the tuple from the function one must analyse the bytecode of the function. This is because the first bytecode in the function literally translates into the tuple argument being unpacked. Assuming the tuple parameter is named <code class="docutils literal notranslate"><span class="pre">.1</span></code> and is expected to unpack to variables <code class="docutils literal notranslate"><span class="pre">spam</span></code> and <code class="docutils literal notranslate"><span class="pre">monty</span></code> (meaning it is the tuple <code class="docutils literal notranslate"><span class="pre">(spam,</span> <span class="pre">monty)</span></code>), the first bytecode in the function will be for the statement <code class="docutils literal notranslate"><span class="pre">spam,</span> <span class="pre">monty</span> <span class="pre">=</span> <span class="pre">.1</span></code>. This means that to know all of the details of the tuple parameter one must look at the initial bytecode of the function to detect tuple unpacking for parameters formatted as <code class="docutils literal notranslate"><span class="pre">\.\d+</span></code> and deduce any and all information about the expected argument. Bytecode analysis is how the <code class="docutils literal notranslate"><span class="pre">inspect.getargspec</span></code> function is able to provide information on tuple parameters. This is not easy to do and is burdensome on introspection tools as they must know how Python bytecode works (an otherwise unneeded burden as all other types of parameters do not require knowledge of Python bytecode).</p> <p>The difficulty of analysing bytecode not withstanding, there is another issue with the dependency on using Python bytecode. IronPython <a class="footnote-reference brackets" href="#ironpython" id="id1">[3]</a> does not use Python’s bytecode. Because it is based on the .NET framework it instead stores MSIL <a class="footnote-reference brackets" href="#msil" id="id2">[4]</a> in <code class="docutils literal notranslate"><span class="pre">func_code.co_code</span></code> attribute of the function. This fact prevents the <code class="docutils literal notranslate"><span class="pre">inspect.getargspec</span></code> function from working when run under IronPython. It is unknown whether other Python implementations are affected but is reasonable to assume if the implementation is not just a re-implementation of the Python virtual machine.</p> </section> <section id="no-loss-of-abilities-if-removed"> <h3><a class="toc-backref" href="#no-loss-of-abilities-if-removed" role="doc-backlink">No Loss of Abilities If Removed</a></h3> <p>As mentioned in <a class="reference internal" href="#introspection-issues">Introspection Issues</a>, to handle tuple parameters the function’s bytecode starts with the bytecode required to unpack the argument into the proper parameter names. This means that there is no special support required to implement tuple parameters and thus there is no loss of abilities if they were to be removed, only a possible convenience (which is addressed in <a class="reference internal" href="#why-they-should-supposedly-stay">Why They Should (Supposedly) Stay</a>).</p> <p>The example function at the beginning of this PEP could easily be rewritten as:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">fxn</span><span class="p">(</span><span class="n">a</span><span class="p">,</span> <span class="n">b_c</span><span class="p">,</span> <span class="n">d</span><span class="p">):</span> <span class="n">b</span><span class="p">,</span> <span class="n">c</span> <span class="o">=</span> <span class="n">b_c</span> <span class="k">pass</span> </pre></div> </div> <p>and in no way lose functionality.</p> </section> <section id="exception-to-the-rule"> <h3><a class="toc-backref" href="#exception-to-the-rule" role="doc-backlink">Exception To The Rule</a></h3> <p>When looking at the various types of parameters that a Python function can have, one will notice that tuple parameters tend to be an exception rather than the rule.</p> <p>Consider <a class="pep reference internal" href="../pep-3102/" title="PEP 3102 – Keyword-Only Arguments">PEP 3102</a> (keyword-only arguments) and <a class="pep reference internal" href="../pep-3107/" title="PEP 3107 – Function Annotations">PEP 3107</a> (function annotations). Both PEPs have been accepted and introduce new functionality within a function’s signature. And yet for both PEPs the new feature cannot be applied to tuple parameters as a whole. <a class="pep reference internal" href="../pep-3102/" title="PEP 3102 – Keyword-Only Arguments">PEP 3102</a> has no support for tuple parameters at all (which makes sense as there is no way to reference a tuple parameter by name). <a class="pep reference internal" href="../pep-3107/" title="PEP 3107 – Function Annotations">PEP 3107</a> allows annotations for each item within the tuple (e.g., <code class="docutils literal notranslate"><span class="pre">(x:int,</span> <span class="pre">y:int)</span></code>), but not the whole tuple (e.g., <code class="docutils literal notranslate"><span class="pre">(x,</span> <span class="pre">y):int</span></code>).</p> <p>The existence of tuple parameters also places sequence objects separately from mapping objects in a function signature. There is no way to pass in a mapping object (e.g., a dict) as a parameter and have it unpack in the same fashion as a sequence does into a tuple parameter.</p> </section> <section id="uninformative-error-messages"> <h3><a class="toc-backref" href="#uninformative-error-messages" role="doc-backlink">Uninformative Error Messages</a></h3> <p>Consider the following function:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">fxn</span><span class="p">((</span><span class="n">a</span><span class="p">,</span> <span class="n">b</span><span class="p">),</span> <span class="p">(</span><span class="n">c</span><span class="p">,</span> <span class="n">d</span><span class="p">)):</span> <span class="k">pass</span> </pre></div> </div> <p>If called as <code class="docutils literal notranslate"><span class="pre">fxn(1,</span> <span class="pre">(2,</span> <span class="pre">3))</span></code> one is given the error message <code class="docutils literal notranslate"><span class="pre">TypeError:</span> <span class="pre">unpack</span> <span class="pre">non-sequence</span></code>. This error message in no way tells you which tuple was not unpacked properly. There is also no indication that this was a result that occurred because of the arguments. Other error messages regarding arguments to functions explicitly state its relation to the signature: <code class="docutils literal notranslate"><span class="pre">TypeError:</span> <span class="pre">fxn()</span> <span class="pre">takes</span> <span class="pre">exactly</span> <span class="pre">2</span> <span class="pre">arguments</span> <span class="pre">(0</span> <span class="pre">given)</span></code>, etc.</p> </section> <section id="little-usage"> <h3><a class="toc-backref" href="#little-usage" role="doc-backlink">Little Usage</a></h3> <p>While an informal poll of the handful of Python programmers I know personally and from the PyCon 2007 sprint indicates a huge majority of people do not know of this feature and the rest just do not use it, some hard numbers is needed to back up the claim that the feature is not heavily used.</p> <p>Iterating over every line in Python’s code repository in the <code class="docutils literal notranslate"><span class="pre">Lib/</span></code> directory using the regular expression <code class="docutils literal notranslate"><span class="pre">^\s*def\s*\w+\s*\(</span></code> to detect function and method definitions there were 22,252 matches in the trunk.</p> <p>Tacking on <code class="docutils literal notranslate"><span class="pre">.*,\s*\(</span></code> to find <code class="docutils literal notranslate"><span class="pre">def</span></code> statements that contained a tuple parameter, only 41 matches were found. This means that for <code class="docutils literal notranslate"><span class="pre">def</span></code> statements, only 0.18% of them seem to use a tuple parameter.</p> </section> </section> <section id="why-they-should-supposedly-stay"> <h2><a class="toc-backref" href="#why-they-should-supposedly-stay" role="doc-backlink">Why They Should (Supposedly) Stay</a></h2> <section id="practical-use"> <h3><a class="toc-backref" href="#practical-use" role="doc-backlink">Practical Use</a></h3> <p>In certain instances tuple parameters can be useful. A common example is code that expects a two-item tuple that represents a Cartesian point. While true it is nice to be able to have the unpacking of the x and y coordinates for you, the argument is that this small amount of practical usefulness is heavily outweighed by other issues pertaining to tuple parameters. And as shown in <a class="reference internal" href="#no-loss-of-abilities-if-removed">No Loss Of Abilities If Removed</a>, their use is purely practical and in no way provide a unique ability that cannot be handled in other ways very easily.</p> </section> <section id="self-documentation-for-parameters"> <h3><a class="toc-backref" href="#self-documentation-for-parameters" role="doc-backlink">Self-Documentation For Parameters</a></h3> <p>It has been argued that tuple parameters provide a way of self-documentation for parameters that are expected to be of a certain sequence format. Using our Cartesian point example from <a class="reference internal" href="#practical-use">Practical Use</a>, seeing <code class="docutils literal notranslate"><span class="pre">(x,</span> <span class="pre">y)</span></code> as a parameter in a function makes it obvious that a tuple of length two is expected as an argument for that parameter.</p> <p>But Python provides several other ways to document what parameters are for. Documentation strings are meant to provide enough information needed to explain what arguments are expected. Tuple parameters might tell you the expected length of a sequence argument, it does not tell you what that data will be used for. One must also read the docstring to know what other arguments are expected if not all parameters are tuple parameters.</p> <p>Function annotations (which do not work with tuple parameters) can also supply documentation. Because annotations can be of any form, what was once a tuple parameter can be a single argument parameter with an annotation of <code class="docutils literal notranslate"><span class="pre">tuple</span></code>, <code class="docutils literal notranslate"><span class="pre">tuple(2)</span></code>, <code class="docutils literal notranslate"><span class="pre">Cartesian</span> <span class="pre">point</span></code>, <code class="docutils literal notranslate"><span class="pre">(x,</span> <span class="pre">y)</span></code>, etc. Annotations provide great flexibility for documenting what an argument is expected to be for a parameter, including being a sequence of a certain length.</p> </section> </section> <section id="transition-plan"> <h2><a class="toc-backref" href="#transition-plan" role="doc-backlink">Transition Plan</a></h2> <p>To transition Python 2.x code to 3.x where tuple parameters are removed, two steps are suggested. First, the proper warning is to be emitted when Python’s compiler comes across a tuple parameter in Python 2.6. This will be treated like any other syntactic change that is to occur in Python 3.0 compared to Python 2.6.</p> <p>Second, the 2to3 refactoring tool <a class="footnote-reference brackets" href="#to3" id="id3">[1]</a> will gain a fixer <a class="footnote-reference brackets" href="#fixer" id="id4">[2]</a> for translating tuple parameters to being a single parameter that is unpacked as the first statement in the function. The name of the new parameter will be changed. The new parameter will then be unpacked into the names originally used in the tuple parameter. This means that the following function:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">fxn</span><span class="p">((</span><span class="n">a</span><span class="p">,</span> <span class="p">(</span><span class="n">b</span><span class="p">,</span> <span class="n">c</span><span class="p">))):</span> <span class="k">pass</span> </pre></div> </div> <p>will be translated into:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">fxn</span><span class="p">(</span><span class="n">a_b_c</span><span class="p">):</span> <span class="p">(</span><span class="n">a</span><span class="p">,</span> <span class="p">(</span><span class="n">b</span><span class="p">,</span> <span class="n">c</span><span class="p">))</span> <span class="o">=</span> <span class="n">a_b_c</span> <span class="k">pass</span> </pre></div> </div> <p>As tuple parameters are used by lambdas because of the single expression limitation, they must also be supported. This is done by having the expected sequence argument bound to a single parameter and then indexing on that parameter:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">lambda</span> <span class="p">(</span><span class="n">x</span><span class="p">,</span> <span class="n">y</span><span class="p">):</span> <span class="n">x</span> <span class="o">+</span> <span class="n">y</span> </pre></div> </div> <p>will be translated into:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">lambda</span> <span class="n">x_y</span><span class="p">:</span> <span class="n">x_y</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span> <span class="o">+</span> <span class="n">x_y</span><span class="p">[</span><span class="mi">1</span><span class="p">]</span> </pre></div> </div> </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 refactoring tool (<a class="reference external" href="http://svn.python.org/view/sandbox/trunk/2to3/">http://svn.python.org/view/sandbox/trunk/2to3/</a>)</aside> <aside class="footnote brackets" id="fixer" role="doc-footnote"> <dt class="label" id="fixer">[<a href="#id4">2</a>]</dt> <dd>2to3 fixer (<a class="reference external" href="http://svn.python.org/view/sandbox/trunk/2to3/fixes/fix_tuple_params.py">http://svn.python.org/view/sandbox/trunk/2to3/fixes/fix_tuple_params.py</a>)</aside> <aside class="footnote brackets" id="ironpython" role="doc-footnote"> <dt class="label" id="ironpython">[<a href="#id1">3</a>]</dt> <dd>IronPython (<a class="reference external" href="http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython">http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython</a>)</aside> <aside class="footnote brackets" id="msil" role="doc-footnote"> <dt class="label" id="msil">[<a href="#id2">4</a>]</dt> <dd>Microsoft Intermediate Language (<a class="reference external" href="http://msdn.microsoft.com/library/en-us/cpguide/html/cpconmicrosoftintermediatelanguagemsil.asp?frame=true">http://msdn.microsoft.com/library/en-us/cpguide/html/cpconmicrosoftintermediatelanguagemsil.asp?frame=true</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-3113.rst">https://github.com/python/peps/blob/main/peps/pep-3113.rst</a></p> <p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-3113.rst">2023-09-09 17:39:29 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="#why-they-should-go">Why They Should Go</a><ul> <li><a class="reference internal" href="#introspection-issues">Introspection Issues</a></li> <li><a class="reference internal" href="#no-loss-of-abilities-if-removed">No Loss of Abilities If Removed</a></li> <li><a class="reference internal" href="#exception-to-the-rule">Exception To The Rule</a></li> <li><a class="reference internal" href="#uninformative-error-messages">Uninformative Error Messages</a></li> <li><a class="reference internal" href="#little-usage">Little Usage</a></li> </ul> </li> <li><a class="reference internal" href="#why-they-should-supposedly-stay">Why They Should (Supposedly) Stay</a><ul> <li><a class="reference internal" href="#practical-use">Practical Use</a></li> <li><a class="reference internal" href="#self-documentation-for-parameters">Self-Documentation For Parameters</a></li> </ul> </li> <li><a class="reference internal" href="#transition-plan">Transition Plan</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-3113.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>