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 317 – Eliminate Implicit Exception Instantiation | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0317/"> <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 317 – Eliminate Implicit Exception Instantiation | peps.python.org'> <meta property="og:description" content="“For clarity in new code, the form raise class(argument, ...) is recommended (i.e. make an explicit call to the constructor).”"> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0317/"> <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="“For clarity in new code, the form raise class(argument, ...) is recommended (i.e. make an explicit call to the constructor).”"> <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 317</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 317 – Eliminate Implicit Exception Instantiation</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author<span class="colon">:</span></dt> <dd class="field-odd">Steven Taschuk <staschuk at telusplanet.net></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">06-May-2003</dd> <dt class="field-odd">Python-Version<span class="colon">:</span></dt> <dd class="field-odd">2.4</dd> <dt class="field-even">Post-History<span class="colon">:</span></dt> <dd class="field-even">09-Jun-2003</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="#motivation">Motivation</a><ul> <li><a class="reference internal" href="#string-exceptions">String Exceptions</a></li> <li><a class="reference internal" href="#implicit-instantiation">Implicit Instantiation</a></li> </ul> </li> <li><a class="reference internal" href="#specification">Specification</a></li> <li><a class="reference internal" href="#backwards-compatibility">Backwards Compatibility</a><ul> <li><a class="reference internal" href="#migration-plan">Migration Plan</a><ul> <li><a class="reference internal" href="#future-statement">Future Statement</a></li> <li><a class="reference internal" href="#warnings">Warnings</a></li> </ul> </li> <li><a class="reference internal" href="#examples">Examples</a><ul> <li><a class="reference internal" href="#code-using-implicit-instantiation">Code Using Implicit Instantiation</a></li> <li><a class="reference internal" href="#code-using-string-exceptions">Code Using String Exceptions</a></li> <li><a class="reference internal" href="#code-supplying-a-traceback-object">Code Supplying a Traceback Object</a></li> <li><a class="reference internal" href="#a-failure-of-the-plan">A Failure of the Plan</a></li> </ul> </li> </ul> </li> <li><a class="reference internal" href="#rejection">Rejection</a></li> <li><a class="reference internal" href="#summary-of-discussion">Summary of Discussion</a><ul> <li><a class="reference internal" href="#new-style-exceptions">New-Style Exceptions</a></li> <li><a class="reference internal" href="#ugliness-of-explicit-instantiation">Ugliness of Explicit Instantiation</a></li> <li><a class="reference internal" href="#performance-penalty-of-warnings">Performance Penalty of Warnings</a></li> <li><a class="reference internal" href="#traceback-argument">Traceback Argument</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> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> <blockquote> <div>“For clarity in new code, the form <code class="docutils literal notranslate"><span class="pre">raise</span> <span class="pre">class(argument,</span> <span class="pre">...)</span></code> is recommended (i.e. make an explicit call to the constructor).”<p class="attribution">—Guido van Rossum, in 1997 <a class="footnote-reference brackets" href="#id6" id="id1">[1]</a></p> </div></blockquote> <p>This PEP proposes the formal deprecation and eventual elimination of forms of the <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement which implicitly instantiate an exception. For example, statements such as</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">raise</span> <span class="n">HullBreachError</span> <span class="k">raise</span> <span class="n">KitchenError</span><span class="p">,</span> <span class="s1">'all out of baked beans'</span> </pre></div> </div> <p>must under this proposal be replaced with their synonyms</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">raise</span> <span class="n">HullBreachError</span><span class="p">()</span> <span class="k">raise</span> <span class="n">KitchenError</span><span class="p">(</span><span class="s1">'all out of baked beans'</span><span class="p">)</span> </pre></div> </div> <p>Note that these latter statements are already legal, and that this PEP does not change their meaning.</p> <p>Eliminating these forms of <code class="docutils literal notranslate"><span class="pre">raise</span></code> makes it impossible to use string exceptions; accordingly, this PEP also proposes the formal deprecation and eventual elimination of string exceptions.</p> <p>Adoption of this proposal breaks backwards compatibility. Under the proposed implementation schedule, Python 2.4 will introduce warnings about uses of <code class="docutils literal notranslate"><span class="pre">raise</span></code> which will eventually become incorrect, and Python 3.0 will eliminate them entirely. (It is assumed that this transition period – 2.4 to 3.0 – will be at least one year long, to comply with the guidelines of <a class="pep reference internal" href="../pep-0005/" title="PEP 5 – Guidelines for Language Evolution">PEP 5</a>.)</p> </section> <section id="motivation"> <h2><a class="toc-backref" href="#motivation" role="doc-backlink">Motivation</a></h2> <section id="string-exceptions"> <h3><a class="toc-backref" href="#string-exceptions" role="doc-backlink">String Exceptions</a></h3> <p>It is assumed that removing string exceptions will be uncontroversial, since it has been intended since at least Python 1.5, when the standard exception types were changed to classes <a class="footnote-reference brackets" href="#id6" id="id2">[1]</a>.</p> <p>For the record: string exceptions should be removed because the presence of two kinds of exception complicates the language without any compensation. Instance exceptions are superior because, for example,</p> <ul class="simple"> <li>the class-instance relationship more naturally expresses the relationship between the exception type and value,</li> <li>they can be organized naturally using superclass-subclass relationships, and</li> <li>they can encapsulate error-reporting behaviour (for example).</li> </ul> </section> <section id="implicit-instantiation"> <h3><a class="toc-backref" href="#implicit-instantiation" role="doc-backlink">Implicit Instantiation</a></h3> <p>Guido’s 1997 essay <a class="footnote-reference brackets" href="#id6" id="id3">[1]</a> on changing the standard exceptions into classes makes clear why <code class="docutils literal notranslate"><span class="pre">raise</span></code> can instantiate implicitly:</p> <blockquote> <div>“The raise statement has been extended to allow raising a class exception without explicit instantiation. The following forms, called the “compatibility forms” of the raise statement […] The motivation for introducing the compatibility forms was to allow backward compatibility with old code that raised a standard exception.”</div></blockquote> <p>For example, it was desired that pre-1.5 code which used string exception syntax such as</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">raise</span> <span class="ne">TypeError</span><span class="p">,</span> <span class="s1">'not an int'</span> </pre></div> </div> <p>would work both on versions of Python in which <code class="docutils literal notranslate"><span class="pre">TypeError</span></code> was a string, and on versions in which it was a class.</p> <p>When no such consideration obtains – that is, when the desired exception type is not a string in any version of the software which the code must support – there is no good reason to instantiate implicitly, and it is clearer not to. For example:</p> <ol class="arabic"> <li>In the code<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">try</span><span class="p">:</span> <span class="k">raise</span> <span class="n">MyError</span><span class="p">,</span> <span class="n">raised</span> <span class="k">except</span> <span class="n">MyError</span><span class="p">,</span> <span class="n">caught</span><span class="p">:</span> <span class="k">pass</span> </pre></div> </div> <p>the syntactic parallel between the <code class="docutils literal notranslate"><span class="pre">raise</span></code> and <code class="docutils literal notranslate"><span class="pre">except</span></code> statements strongly suggests that <code class="docutils literal notranslate"><span class="pre">raised</span></code> and <code class="docutils literal notranslate"><span class="pre">caught</span></code> refer to the same object. For string exceptions this actually is the case, but for instance exceptions it is not.</p> </li> <li>When instantiation is implicit, it is not obvious when it occurs, for example, whether it occurs when the exception is raised or when it is caught. Since it actually happens at the <code class="docutils literal notranslate"><span class="pre">raise</span></code>, the code should say so.<p>(Note that at the level of the C API, an exception can be “raised” and “caught” without being instantiated; this is used as an optimization by, for example, <code class="docutils literal notranslate"><span class="pre">PyIter_Next</span></code>. But in Python, no such optimization is or should be available.)</p> </li> <li>An implicitly instantiating <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement with no arguments, such as<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">raise</span> <span class="n">MyError</span> </pre></div> </div> <p>simply does not do what it says: it does not raise the named object.</p> </li> <li>The equivalence of<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">raise</span> <span class="n">MyError</span> <span class="k">raise</span> <span class="n">MyError</span><span class="p">()</span> </pre></div> </div> <p>conflates classes and instances, creating a possible source of confusion for beginners. (Moreover, it is not clear that the interpreter could distinguish between a new-style class and an instance of such a class, so implicit instantiation may be an obstacle to any future plan to let exceptions be new-style objects.)</p> </li> </ol> <p>In short, implicit instantiation has no advantages other than backwards compatibility, and so should be phased out along with what it exists to ensure compatibility with, namely, string exceptions.</p> </section> </section> <section id="specification"> <h2><a class="toc-backref" href="#specification" role="doc-backlink">Specification</a></h2> <p>The syntax of <code class="docutils literal notranslate"><span class="pre">raise_stmt</span></code> <a class="footnote-reference brackets" href="#id7" id="id4">[3]</a> is to be changed from</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">raise_stmt</span> <span class="p">:</span><span class="o">:=</span> <span class="s2">"raise"</span> <span class="p">[</span><span class="n">expression</span> <span class="p">[</span><span class="s2">","</span> <span class="n">expression</span> <span class="p">[</span><span class="s2">","</span> <span class="n">expression</span><span class="p">]]]</span> </pre></div> </div> <p>to</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">raise_stmt</span> <span class="p">:</span><span class="o">:=</span> <span class="s2">"raise"</span> <span class="p">[</span><span class="n">expression</span> <span class="p">[</span><span class="s2">","</span> <span class="n">expression</span><span class="p">]]</span> </pre></div> </div> <p>If no expressions are present, the <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement behaves as it does presently: it re-raises the last exception that was active in the current scope, and if no exception has been active in the current scope, a <code class="docutils literal notranslate"><span class="pre">TypeError</span></code> is raised indicating that this is the problem.</p> <p>Otherwise, the first expression is evaluated, producing the <em>raised object</em>. Then the second expression is evaluated, if present, producing the <em>substituted traceback</em>. If no second expression is present, the substituted traceback is <code class="docutils literal notranslate"><span class="pre">None</span></code>.</p> <p>The raised object must be an instance. The class of the instance is the exception type, and the instance itself is the exception value. If the raised object is not an instance – for example, if it is a class or string – a <code class="docutils literal notranslate"><span class="pre">TypeError</span></code> is raised.</p> <p>If the substituted traceback is not <code class="docutils literal notranslate"><span class="pre">None</span></code>, it must be a traceback object, and it is substituted instead of the current location as the place where the exception occurred. If it is neither a traceback object nor <code class="docutils literal notranslate"><span class="pre">None</span></code>, a <code class="docutils literal notranslate"><span class="pre">TypeError</span></code> is raised.</p> </section> <section id="backwards-compatibility"> <h2><a class="toc-backref" href="#backwards-compatibility" role="doc-backlink">Backwards Compatibility</a></h2> <section id="migration-plan"> <h3><a class="toc-backref" href="#migration-plan" role="doc-backlink">Migration Plan</a></h3> <section id="future-statement"> <h4><a class="toc-backref" href="#future-statement" role="doc-backlink">Future Statement</a></h4> <p>Under the <a class="pep reference internal" href="../pep-0236/" title="PEP 236 – Back to the __future__">PEP 236</a> future statement:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span><span class="w"> </span><span class="nn">__future__</span><span class="w"> </span><span class="kn">import</span> <span class="n">raise_with_two_args</span> </pre></div> </div> <p>the syntax and semantics of the <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement will be as described above. This future feature is to appear in Python 2.4; its effect is to become standard in Python 3.0.</p> <p>As the examples below illustrate, this future statement is only needed for code which uses the substituted traceback argument to <code class="docutils literal notranslate"><span class="pre">raise</span></code>; simple exception raising does not require it.</p> </section> <section id="warnings"> <h4><a class="toc-backref" href="#warnings" role="doc-backlink">Warnings</a></h4> <p>Three new <a class="pep reference internal" href="../pep-0230/" title="PEP 230 – Warning Framework">warnings</a>, all of category <code class="docutils literal notranslate"><span class="pre">DeprecationWarning</span></code>, are to be issued to point out uses of <code class="docutils literal notranslate"><span class="pre">raise</span></code> which will become incorrect under the proposed changes.</p> <p>The first warning is issued when a <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement is executed in which the first expression evaluates to a string. The message for this warning is:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">raising</span> <span class="n">strings</span> <span class="n">will</span> <span class="n">be</span> <span class="n">impossible</span> <span class="ow">in</span> <span class="n">the</span> <span class="n">future</span> </pre></div> </div> <p>The second warning is issued when a <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement is executed in which the first expression evaluates to a class. The message for this warning is:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">raising</span> <span class="n">classes</span> <span class="n">will</span> <span class="n">be</span> <span class="n">impossible</span> <span class="ow">in</span> <span class="n">the</span> <span class="n">future</span> </pre></div> </div> <p>The third warning is issued when a <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement with three expressions is compiled. (Not, note, when it is executed; this is important because the <code class="docutils literal notranslate"><span class="pre">SyntaxError</span></code> which this warning presages will occur at compile-time.) The message for this warning is:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">raising</span> <span class="k">with</span> <span class="n">three</span> <span class="n">arguments</span> <span class="n">will</span> <span class="n">be</span> <span class="n">impossible</span> <span class="ow">in</span> <span class="n">the</span> <span class="n">future</span> </pre></div> </div> <p>These warnings are to appear in Python 2.4, and disappear in Python 3.0, when the conditions which cause them are simply errors.</p> </section> </section> <section id="examples"> <h3><a class="toc-backref" href="#examples" role="doc-backlink">Examples</a></h3> <section id="code-using-implicit-instantiation"> <h4><a class="toc-backref" href="#code-using-implicit-instantiation" role="doc-backlink">Code Using Implicit Instantiation</a></h4> <p>Code such as</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">class</span><span class="w"> </span><span class="nc">MyError</span><span class="p">(</span><span class="ne">Exception</span><span class="p">):</span> <span class="k">pass</span> <span class="k">raise</span> <span class="n">MyError</span><span class="p">,</span> <span class="s1">'spam'</span> </pre></div> </div> <p>will issue a warning when the <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement is executed. The <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement should be changed to instantiate explicitly:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">raise</span> <span class="n">MyError</span><span class="p">(</span><span class="s1">'spam'</span><span class="p">)</span> </pre></div> </div> </section> <section id="code-using-string-exceptions"> <h4><a class="toc-backref" href="#code-using-string-exceptions" role="doc-backlink">Code Using String Exceptions</a></h4> <p>Code such as</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">MyError</span> <span class="o">=</span> <span class="s1">'spam'</span> <span class="k">raise</span> <span class="n">MyError</span><span class="p">,</span> <span class="s1">'eggs'</span> </pre></div> </div> <p>will issue a warning when the <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement is executed. The exception type should be changed to a class:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">class</span><span class="w"> </span><span class="nc">MyError</span><span class="p">(</span><span class="ne">Exception</span><span class="p">):</span> <span class="k">pass</span> </pre></div> </div> <p>and, as in the previous example, the <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement should be changed to instantiate explicitly</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">raise</span> <span class="n">MyError</span><span class="p">(</span><span class="s1">'eggs'</span><span class="p">)</span> </pre></div> </div> </section> <section id="code-supplying-a-traceback-object"> <h4><a class="toc-backref" href="#code-supplying-a-traceback-object" role="doc-backlink">Code Supplying a Traceback Object</a></h4> <p>Code such as</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">raise</span> <span class="n">MyError</span><span class="p">,</span> <span class="s1">'spam'</span><span class="p">,</span> <span class="n">mytraceback</span> </pre></div> </div> <p>will issue a warning when compiled. The statement should be changed to</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">raise</span> <span class="n">MyError</span><span class="p">(</span><span class="s1">'spam'</span><span class="p">),</span> <span class="n">mytraceback</span> </pre></div> </div> <p>and the future statement</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span><span class="w"> </span><span class="nn">__future__</span><span class="w"> </span><span class="kn">import</span> <span class="n">raise_with_two_args</span> </pre></div> </div> <p>should be added at the top of the module. Note that adding this future statement also turns the other two warnings into errors, so the changes described in the previous examples must also be applied.</p> <p>The special case</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">raise</span> <span class="n">sys</span><span class="o">.</span><span class="n">exc_type</span><span class="p">,</span> <span class="n">sys</span><span class="o">.</span><span class="n">exc_info</span><span class="p">,</span> <span class="n">sys</span><span class="o">.</span><span class="n">exc_traceback</span> </pre></div> </div> <p>(which is intended to re-raise a previous exception) should be changed simply to</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">raise</span> </pre></div> </div> </section> <section id="a-failure-of-the-plan"> <h4><a class="toc-backref" href="#a-failure-of-the-plan" role="doc-backlink">A Failure of the Plan</a></h4> <p>It may occur that a <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement which raises a string or implicitly instantiates is not executed in production or testing during the phase-in period for this PEP. In that case, it will not issue any warnings, but will instead suddenly fail one day in Python 3.0 or a subsequent version. (The failure is that the wrong exception gets raised, namely a <code class="docutils literal notranslate"><span class="pre">TypeError</span></code> complaining about the arguments to <code class="docutils literal notranslate"><span class="pre">raise</span></code>, instead of the exception intended.)</p> <p>Such cases can be made rarer by prolonging the phase-in period; they cannot be made impossible short of issuing at compile-time a warning for every <code class="docutils literal notranslate"><span class="pre">raise</span></code> statement.</p> </section> </section> </section> <section id="rejection"> <h2><a class="toc-backref" href="#rejection" role="doc-backlink">Rejection</a></h2> <p>If this PEP were accepted, nearly all existing Python code would need to be reviewed and probably revised; even if all the above arguments in favour of explicit instantiation are accepted, the improvement in clarity is too minor to justify the cost of doing the revision and the risk of new bugs introduced thereby.</p> <p>This proposal has therefore been rejected <a class="footnote-reference brackets" href="#id8" id="id5">[6]</a>.</p> <p>Note that string exceptions are slated for removal independently of this proposal; what is rejected is the removal of implicit exception instantiation.</p> </section> <section id="summary-of-discussion"> <h2><a class="toc-backref" href="#summary-of-discussion" role="doc-backlink">Summary of Discussion</a></h2> <p>A small minority of respondents were in favour of the proposal, but the dominant response was that any such migration would be costly out of proportion to the putative benefit. As noted above, this point is sufficient in itself to reject the PEP.</p> <section id="new-style-exceptions"> <h3><a class="toc-backref" href="#new-style-exceptions" role="doc-backlink">New-Style Exceptions</a></h3> <p>Implicit instantiation might conflict with future plans to allow instances of new-style classes to be used as exceptions. In order to decide whether to instantiate implicitly, the <code class="docutils literal notranslate"><span class="pre">raise</span></code> machinery must determine whether the first argument is a class or an instance – but with new-style classes there is no clear and strong distinction.</p> <p>Under this proposal, the problem would be avoided because the exception would already have been instantiated. However, there are two plausible alternative solutions:</p> <ol class="arabic"> <li>Require exception types to be subclasses of <code class="docutils literal notranslate"><span class="pre">Exception</span></code>, and instantiate implicitly if and only if<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="nb">issubclass</span><span class="p">(</span><span class="n">firstarg</span><span class="p">,</span> <span class="ne">Exception</span><span class="p">)</span> </pre></div> </div> </li> <li>Instantiate implicitly if and only if<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="nb">isinstance</span><span class="p">(</span><span class="n">firstarg</span><span class="p">,</span> <span class="nb">type</span><span class="p">)</span> </pre></div> </div> </li> </ol> <p>Thus eliminating implicit instantiation entirely is not necessary to solve this problem.</p> </section> <section id="ugliness-of-explicit-instantiation"> <h3><a class="toc-backref" href="#ugliness-of-explicit-instantiation" role="doc-backlink">Ugliness of Explicit Instantiation</a></h3> <p>Some respondents felt that the explicitly instantiating syntax is uglier, especially in cases when no arguments are supplied to the exception constructor:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">raise</span> <span class="ne">TypeError</span><span class="p">()</span> </pre></div> </div> <p>The problem is particularly acute when the exception instance itself is not of interest, that is, when the only relevant point is the exception type:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">try</span><span class="p">:</span> <span class="c1"># ... deeply nested search loop ...</span> <span class="k">raise</span> <span class="n">Found</span> <span class="k">except</span> <span class="n">Found</span><span class="p">:</span> <span class="c1"># ...</span> </pre></div> </div> <p>In such cases the symmetry between <code class="docutils literal notranslate"><span class="pre">raise</span></code> and <code class="docutils literal notranslate"><span class="pre">except</span></code> can be more expressive of the intent of the code.</p> <p>Guido opined that the implicitly instantiating syntax is “a tad prettier” even for cases with a single argument, since it has less punctuation.</p> </section> <section id="performance-penalty-of-warnings"> <h3><a class="toc-backref" href="#performance-penalty-of-warnings" role="doc-backlink">Performance Penalty of Warnings</a></h3> <p>Experience with deprecating <code class="docutils literal notranslate"><span class="pre">apply()</span></code> shows that use of the warning framework can incur a significant performance penalty.</p> <p>Code which instantiates explicitly would not be affected, since the run-time checks necessary to determine whether to issue a warning are exactly those which are needed to determine whether to instantiate implicitly in the first place. That is, such statements are already incurring the cost of these checks.</p> <p>Code which instantiates implicitly would incur a large cost: timing trials indicate that issuing a warning (whether it is suppressed or not) takes about five times more time than simply instantiating, raising, and catching an exception.</p> <p>This penalty is mitigated by the fact that <code class="docutils literal notranslate"><span class="pre">raise</span></code> statements are rarely on performance-critical execution paths.</p> </section> <section id="traceback-argument"> <h3><a class="toc-backref" href="#traceback-argument" role="doc-backlink">Traceback Argument</a></h3> <p>As the proposal stands, it would be impossible to use the traceback argument to <code class="docutils literal notranslate"><span class="pre">raise</span></code> conveniently with all 2.x versions of Python.</p> <p>For compatibility with versions < 2.4, the three-argument form must be used; but this form would produce warnings with versions >= 2.4. Those warnings could be suppressed, but doing so is awkward because the relevant type of warning is issued at compile-time.</p> <p>If this PEP were still under consideration, this objection would be met by extending the phase-in period. For example, warnings could first be issued in 3.0, and become errors in some later release.</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="id6" role="doc-footnote"> <dt class="label" id="id6">[1]<em> (<a href='#id1'>1</a>, <a href='#id2'>2</a>, <a href='#id3'>3</a>) </em></dt> <dd>“Standard Exception Classes in Python 1.5”, Guido van Rossum. <a class="reference external" href="http://www.python.org/doc/essays/stdexceptions.html">http://www.python.org/doc/essays/stdexceptions.html</a></aside> <aside class="footnote brackets" id="id7" role="doc-footnote"> <dt class="label" id="id7">[<a href="#id4">3</a>]</dt> <dd>“Python Language Reference”, Guido van Rossum. <a class="reference external" href="http://docs.python.org/reference/simple_stmts.html#raise">http://docs.python.org/reference/simple_stmts.html#raise</a></aside> <aside class="footnote brackets" id="id8" role="doc-footnote"> <dt class="label" id="id8">[<a href="#id5">6</a>]</dt> <dd>Guido van Rossum, 11 June 2003 post to <code class="docutils literal notranslate"><span class="pre">python-dev</span></code>. <a class="reference external" href="https://mail.python.org/pipermail/python-dev/2003-June/036176.html">https://mail.python.org/pipermail/python-dev/2003-June/036176.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-0317.rst">https://github.com/python/peps/blob/main/peps/pep-0317.rst</a></p> <p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0317.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="#motivation">Motivation</a><ul> <li><a class="reference internal" href="#string-exceptions">String Exceptions</a></li> <li><a class="reference internal" href="#implicit-instantiation">Implicit Instantiation</a></li> </ul> </li> <li><a class="reference internal" href="#specification">Specification</a></li> <li><a class="reference internal" href="#backwards-compatibility">Backwards Compatibility</a><ul> <li><a class="reference internal" href="#migration-plan">Migration Plan</a><ul> <li><a class="reference internal" href="#future-statement">Future Statement</a></li> <li><a class="reference internal" href="#warnings">Warnings</a></li> </ul> </li> <li><a class="reference internal" href="#examples">Examples</a><ul> <li><a class="reference internal" href="#code-using-implicit-instantiation">Code Using Implicit Instantiation</a></li> <li><a class="reference internal" href="#code-using-string-exceptions">Code Using String Exceptions</a></li> <li><a class="reference internal" href="#code-supplying-a-traceback-object">Code Supplying a Traceback Object</a></li> <li><a class="reference internal" href="#a-failure-of-the-plan">A Failure of the Plan</a></li> </ul> </li> </ul> </li> <li><a class="reference internal" href="#rejection">Rejection</a></li> <li><a class="reference internal" href="#summary-of-discussion">Summary of Discussion</a><ul> <li><a class="reference internal" href="#new-style-exceptions">New-Style Exceptions</a></li> <li><a class="reference internal" href="#ugliness-of-explicit-instantiation">Ugliness of Explicit Instantiation</a></li> <li><a class="reference internal" href="#performance-penalty-of-warnings">Performance Penalty of Warnings</a></li> <li><a class="reference internal" href="#traceback-argument">Traceback Argument</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-0317.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>