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 224 – Attribute Docstrings | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0224/"> <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 224 – Attribute Docstrings | peps.python.org'> <meta property="og:description" content="This PEP describes the “attribute docstring” proposal for Python 2.0. This PEP tracks the status and ownership of this feature. It contains a description of the feature and outlines changes necessary to support the feature. The CVS revision history of..."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0224/"> <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 PEP describes the “attribute docstring” proposal for Python 2.0. This PEP tracks the status and ownership of this feature. It contains a description of the feature and outlines changes necessary to support the feature. The CVS revision history of..."> <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 224</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 224 – Attribute Docstrings</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author<span class="colon">:</span></dt> <dd class="field-odd">Marc-André Lemburg <mal at lemburg.com></dd> <dt class="field-even">Status<span class="colon">:</span></dt> <dd class="field-even"><abbr title="Formally declined and will not be accepted">Rejected</abbr></dd> <dt class="field-odd">Type<span class="colon">:</span></dt> <dd class="field-odd"><abbr title="Normative PEP with a new feature for Python, implementation change for CPython or interoperability standard for the ecosystem">Standards Track</abbr></dd> <dt class="field-even">Created<span class="colon">:</span></dt> <dd class="field-even">23-Aug-2000</dd> <dt class="field-odd">Python-Version<span class="colon">:</span></dt> <dd class="field-odd">2.1</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="#introduction">Introduction</a></li> <li><a class="reference internal" href="#rationale">Rationale</a></li> <li><a class="reference internal" href="#implementation">Implementation</a></li> <li><a class="reference internal" href="#caveats-of-the-implementation">Caveats of the Implementation</a></li> <li><a class="reference internal" href="#possible-problems">Possible Problems</a></li> <li><a class="reference internal" href="#comments-from-our-bdfl">Comments from our BDFL</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> <li><a class="reference internal" href="#references">References</a></li> </ul> </details></section> <div class="pep-banner sticky-banner deprecated rejected admonition warning"> <p class="admonition-title">Warning</p> <p>This PEP has been rejected.</p> <p class="close-button">×</p> <p>See <a class="reference internal" href="#rejection"><span class="std std-ref">Comments from our BDFL</span></a> for more information.</p> <p></p> </div> <section id="introduction"> <h2><a class="toc-backref" href="#introduction" role="doc-backlink">Introduction</a></h2> <p>This PEP describes the “attribute docstring” proposal for Python 2.0. This PEP tracks the status and ownership of this feature. It contains a description of the feature and outlines changes necessary to support the feature. The CVS revision history of this file contains the definitive historical record.</p> </section> <section id="rationale"> <h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2> <p>This PEP proposes a small addition to the way Python currently handles docstrings embedded in Python code.</p> <p>Python currently only handles the case of docstrings which appear directly after a class definition, a function definition or as first string literal in a module. The string literals are added to the objects in question under the <code class="docutils literal notranslate"><span class="pre">__doc__</span></code> attribute and are from then on available for introspection tools which can extract the contained information for help, debugging and documentation purposes.</p> <p>Docstrings appearing in locations other than the ones mentioned are simply ignored and don’t result in any code generation.</p> <p>Here is an example:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">C</span><span class="p">:</span> <span class="s2">"class C doc-string"</span> <span class="n">a</span> <span class="o">=</span> <span class="mi">1</span> <span class="s2">"attribute C.a doc-string (1)"</span> <span class="n">b</span> <span class="o">=</span> <span class="mi">2</span> <span class="s2">"attribute C.b doc-string (2)"</span> </pre></div> </div> <p>The docstrings (1) and (2) are currently being ignored by the Python byte code compiler, but could obviously be put to good use for documenting the named assignments that precede them.</p> <p>This PEP proposes to also make use of these cases by proposing semantics for adding their content to the objects in which they appear under new generated attribute names.</p> <p>The original idea behind this approach which also inspired the above example was to enable inline documentation of class attributes, which can currently only be documented in the class’s docstring or using comments which are not available for introspection.</p> </section> <section id="implementation"> <h2><a class="toc-backref" href="#implementation" role="doc-backlink">Implementation</a></h2> <p>Docstrings are handled by the byte code compiler as expressions. The current implementation special cases the few locations mentioned above to make use of these expressions, but otherwise ignores the strings completely.</p> <p>To enable use of these docstrings for documenting named assignments (which is the natural way of defining e.g. class attributes), the compiler will have to keep track of the last assigned name and then use this name to assign the content of the docstring to an attribute of the containing object by means of storing it in as a constant which is then added to the object’s namespace during object construction time.</p> <p>In order to preserve features like inheritance and hiding of Python’s special attributes (ones with leading and trailing double underscores), a special name mangling has to be applied which uniquely identifies the docstring as belonging to the name assignment and allows finding the docstring later on by inspecting the namespace.</p> <p>The following name mangling scheme achieves all of the above:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">__doc_</span><span class="o"><</span><span class="n">attributename</span><span class="o">></span><span class="n">__</span> </pre></div> </div> <p>To keep track of the last assigned name, the byte code compiler stores this name in a variable of the compiling structure. This variable defaults to NULL. When it sees a docstring, it then checks the variable and uses the name as basis for the above name mangling to produce an implicit assignment of the docstring to the mangled name. It then resets the variable to NULL to avoid duplicate assignments.</p> <p>If the variable does not point to a name (i.e. is NULL), no assignments are made. These will continue to be ignored like before. All classical docstrings fall under this case, so no duplicate assignments are done.</p> <p>In the above example this would result in the following new class attributes to be created:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">C</span><span class="o">.</span><span class="n">__doc_a__</span> <span class="o">==</span> <span class="s2">"attribute C.a doc-string (1)"</span> <span class="n">C</span><span class="o">.</span><span class="n">__doc_b__</span> <span class="o">==</span> <span class="s2">"attribute C.b doc-string (2)"</span> </pre></div> </div> <p>A patch to the current CVS version of Python 2.0 which implements the above is available on SourceForge at <a class="footnote-reference brackets" href="#id2" id="id1">[1]</a>.</p> </section> <section id="caveats-of-the-implementation"> <h2><a class="toc-backref" href="#caveats-of-the-implementation" role="doc-backlink">Caveats of the Implementation</a></h2> <p>Since the implementation does not reset the compiling structure variable when processing a non-expression, e.g. a function definition, the last assigned name remains active until either the next assignment or the next occurrence of a docstring.</p> <p>This can lead to cases where the docstring and assignment may be separated by other expressions:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">C</span><span class="p">:</span> <span class="s2">"C doc string"</span> <span class="n">b</span> <span class="o">=</span> <span class="mi">2</span> <span class="k">def</span> <span class="nf">x</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span> <span class="s2">"C.x doc string"</span> <span class="n">y</span> <span class="o">=</span> <span class="mi">3</span> <span class="k">return</span> <span class="mi">1</span> <span class="s2">"b's doc string"</span> </pre></div> </div> <p>Since the definition of method “x” currently does not reset the used assignment name variable, it is still valid when the compiler reaches the docstring “b’s doc string” and thus assigns the string to <code class="docutils literal notranslate"><span class="pre">__doc_b__</span></code>.</p> <p>A possible solution to this problem would be resetting the name variable for all non-expression nodes in the compiler.</p> </section> <section id="possible-problems"> <h2><a class="toc-backref" href="#possible-problems" role="doc-backlink">Possible Problems</a></h2> <p>Even though highly unlikely, attribute docstrings could get accidentally concatenated to the attribute’s value:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">C</span><span class="p">:</span> <span class="n">x</span> <span class="o">=</span> <span class="s2">"text"</span> \ <span class="s2">"x's docstring"</span> </pre></div> </div> <p>The trailing slash would cause the Python compiler to concatenate the attribute value and the docstring.</p> <p>A modern syntax highlighting editor would easily make this accident visible, though, and by simply inserting empty lines between the attribute definition and the docstring you can avoid the possible concatenation completely, so the problem is negligible.</p> <p>Another possible problem is that of using triple quoted strings as a way to uncomment parts of your code.</p> <p>If there happens to be an assignment just before the start of the comment string, then the compiler will treat the comment as docstring attribute and apply the above logic to it.</p> <p>Besides generating a docstring for an otherwise undocumented attribute there is no breakage.</p> </section> <section id="comments-from-our-bdfl"> <span id="rejection"></span><h2><a class="toc-backref" href="#comments-from-our-bdfl" role="doc-backlink">Comments from our BDFL</a></h2> <p>Early comments on the PEP from Guido:</p> <blockquote> <div>I “kinda” like the idea of having attribute docstrings (meaning it’s not of great importance to me) but there are two things I don’t like in your current proposal:<ol class="arabic simple"> <li>The syntax you propose is too ambiguous: as you say, stand-alone string literal are used for other purposes and could suddenly become attribute docstrings.</li> <li>I don’t like the access method either (<code class="docutils literal notranslate"><span class="pre">__doc_<attrname>__</span></code>).</li> </ol> </div></blockquote> <p>The author’s reply:</p> <blockquote> <div><div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">></span> <span class="mf">1.</span> <span class="n">The</span> <span class="n">syntax</span> <span class="n">you</span> <span class="n">propose</span> <span class="ow">is</span> <span class="n">too</span> <span class="n">ambiguous</span><span class="p">:</span> <span class="k">as</span> <span class="n">you</span> <span class="n">say</span><span class="p">,</span> <span class="n">stand</span><span class="o">-</span><span class="n">alone</span> <span class="o">></span> <span class="n">string</span> <span class="n">literal</span> <span class="n">are</span> <span class="n">used</span> <span class="k">for</span> <span class="n">other</span> <span class="n">purposes</span> <span class="ow">and</span> <span class="n">could</span> <span class="n">suddenly</span> <span class="o">></span> <span class="n">become</span> <span class="n">attribute</span> <span class="n">docstrings</span><span class="o">.</span> </pre></div> </div> <p>This can be fixed by introducing some extra checks in the compiler to reset the “doc attribute” flag in the compiler struct.</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">></span> <span class="mf">2.</span> <span class="n">I</span> <span class="n">don</span><span class="s1">'t like the access method either (``__doc_<attrname>__``).</span> </pre></div> </div> <p>Any other name will do. It will only have to match these criteria:</p> <ul class="simple"> <li>must start with two underscores (to match <code class="docutils literal notranslate"><span class="pre">__doc__</span></code>)</li> <li>must be extractable using some form of inspection (e.g. by using a naming convention which includes some fixed name part)</li> <li>must be compatible with class inheritance (i.e. should be stored as attribute)</li> </ul> </div></blockquote> <p>Later on in March, Guido pronounced on this PEP in March 2001 (on python-dev). Here are his reasons for rejection mentioned in private mail to the author of this PEP:</p> <blockquote> <div>…<p>It might be useful, but I really hate the proposed syntax.</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">a</span> <span class="o">=</span> <span class="mi">1</span> <span class="s2">"foo bar"</span> <span class="n">b</span> <span class="o">=</span> <span class="mi">1</span> </pre></div> </div> <p>I really have no way to know whether “foo bar” is a docstring for a or for b.</p> <p>…</p> <p>You can use this convention:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">a</span> <span class="o">=</span> <span class="mi">1</span> <span class="n">__doc_a__</span> <span class="o">=</span> <span class="s2">"doc string for a"</span> </pre></div> </div> <p>This makes it available at runtime.</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span>> Are you completely opposed to adding attribute documentation > to Python or is it just the way the implementation works ? I > find the syntax proposed in the PEP very intuitive and many > other users on c.l.p and in private emails have supported it > at the time I wrote the PEP. </pre></div> </div> <p>It’s not the implementation, it’s the syntax. It doesn’t convey a clear enough coupling between the variable and the doc string.</p> </div></blockquote> </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 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="id2" role="doc-footnote"> <dt class="label" id="id2">[<a href="#id1">1</a>]</dt> <dd><a class="reference external" href="http://sourceforge.net/patch/?func=detailpatch&patch_id=101264&group_id=5470">http://sourceforge.net/patch/?func=detailpatch&patch_id=101264&group_id=5470</a></aside> </aside> </section> </section> <hr class="docutils" /> <p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0224.rst">https://github.com/python/peps/blob/main/peps/pep-0224.rst</a></p> <p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0224.rst">2024-04-14 20:08:31 GMT</a></p> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#introduction">Introduction</a></li> <li><a class="reference internal" href="#rationale">Rationale</a></li> <li><a class="reference internal" href="#implementation">Implementation</a></li> <li><a class="reference internal" href="#caveats-of-the-implementation">Caveats of the Implementation</a></li> <li><a class="reference internal" href="#possible-problems">Possible Problems</a></li> <li><a class="reference internal" href="#comments-from-our-bdfl">Comments from our BDFL</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> <li><a class="reference internal" href="#references">References</a></li> </ul> <br> <a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0224.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>