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 264 – Future statements in simulated shells | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0264/"> <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 264 – Future statements in simulated shells | peps.python.org'> <meta property="og:description" content="As noted in PEP 236, there is no clear way for “simulated interactive shells” to simulate the behaviour of __future__ statements in “real” interactive shells, i.e. have __future__ statements’ effects last the life of the shell."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0264/"> <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="As noted in PEP 236, there is no clear way for “simulated interactive shells” to simulate the behaviour of __future__ statements in “real” interactive shells, i.e. have __future__ statements’ effects last the life of the shell."> <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 264</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 264 – Future statements in simulated shells</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author<span class="colon">:</span></dt> <dd class="field-odd">Michael Hudson <mwh at python.net></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">Requires<span class="colon">:</span></dt> <dd class="field-even"><a class="reference external" href="../pep-0236/">236</a></dd> <dt class="field-odd">Created<span class="colon">:</span></dt> <dd class="field-odd">30-Jul-2001</dd> <dt class="field-even">Python-Version<span class="colon">:</span></dt> <dd class="field-even">2.2</dd> <dt class="field-odd">Post-History<span class="colon">:</span></dt> <dd class="field-odd">30-Jul-2001</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="#specification">Specification</a></li> <li><a class="reference internal" href="#backward-compatibility">Backward Compatibility</a></li> <li><a class="reference internal" href="#forward-compatibility">Forward Compatibility</a></li> <li><a class="reference internal" href="#issues">Issues</a></li> <li><a class="reference internal" href="#implementation">Implementation</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>As noted in <a class="pep reference internal" href="../pep-0236/" title="PEP 236 – Back to the __future__">PEP 236</a>, there is no clear way for “simulated interactive shells” to simulate the behaviour of <code class="docutils literal notranslate"><span class="pre">__future__</span></code> statements in “real” interactive shells, i.e. have <code class="docutils literal notranslate"><span class="pre">__future__</span></code> statements’ effects last the life of the shell.</p> <p>The PEP also takes the opportunity to clean up the other unresolved issue mentioned in <a class="pep reference internal" href="../pep-0236/" title="PEP 236 – Back to the __future__">PEP 236</a>, the inability to stop <code class="docutils literal notranslate"><span class="pre">compile()</span></code> inheriting the effect of future statements affecting the code calling <code class="docutils literal notranslate"><span class="pre">compile()</span></code>.</p> <p>This PEP proposes to address the first problem by adding an optional fourth argument to the builtin function “compile”, adding information to the <code class="docutils literal notranslate"><span class="pre">_Feature</span></code> instances defined in <code class="docutils literal notranslate"><span class="pre">__future__.py</span></code> and adding machinery to the standard library modules “codeop” and “code” to make the construction of such shells easy.</p> <p>The second problem is dealt with by simply adding <em>another</em> optional argument to <code class="docutils literal notranslate"><span class="pre">compile()</span></code>, which if non-zero suppresses the inheriting of future statements’ effects.</p> </section> <section id="specification"> <h2><a class="toc-backref" href="#specification" role="doc-backlink">Specification</a></h2> <p>I propose adding a fourth, optional, “flags” argument to the builtin “compile” function. If this argument is omitted, there will be no change in behaviour from that of Python 2.1.</p> <p>If it is present it is expected to be an integer, representing various possible compile time options as a bitfield. The bitfields will have the same values as the <code class="docutils literal notranslate"><span class="pre">CO_*</span></code> flags already used by the C part of Python interpreter to refer to future statements.</p> <p><code class="docutils literal notranslate"><span class="pre">compile()</span></code> shall raise a <code class="docutils literal notranslate"><span class="pre">ValueError</span></code> exception if it does not recognize any of the bits set in the supplied flags.</p> <p>The flags supplied will be bitwise-“or”ed with the flags that would be set anyway, unless the new fifth optional argument is a non-zero integer, in which case the flags supplied will be exactly the set used.</p> <p>The above-mentioned flags are not currently exposed to Python. I propose adding <code class="docutils literal notranslate"><span class="pre">.compiler_flag</span></code> attributes to the <code class="docutils literal notranslate"><span class="pre">_Feature</span></code> objects in <code class="docutils literal notranslate"><span class="pre">__future__.py</span></code> that contain the necessary bits, so one might write code such as:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">import</span> <span class="nn">__future__</span> <span class="k">def</span> <span class="nf">compile_generator</span><span class="p">(</span><span class="n">func_def</span><span class="p">):</span> <span class="k">return</span> <span class="nb">compile</span><span class="p">(</span><span class="n">func_def</span><span class="p">,</span> <span class="s2">"<input>"</span><span class="p">,</span> <span class="s2">"suite"</span><span class="p">,</span> <span class="n">__future__</span><span class="o">.</span><span class="n">generators</span><span class="o">.</span><span class="n">compiler_flag</span><span class="p">)</span> </pre></div> </div> <p>A recent change means that these same bits can be used to tell if a code object was compiled with a given feature; for instance</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span>codeob.co_flags & __future__.generators.compiler_flag`` </pre></div> </div> <p>will be non-zero if and only if the code object “codeob” was compiled in an environment where generators were allowed.</p> <p>I will also add a <code class="docutils literal notranslate"><span class="pre">.all_feature_flags</span></code> attribute to the <code class="docutils literal notranslate"><span class="pre">__future__</span></code> module, giving a low-effort way of enumerating all the <code class="docutils literal notranslate"><span class="pre">__future__</span></code> options supported by the running interpreter.</p> <p>I also propose adding a pair of classes to the standard library module codeop.</p> <p>One - <code class="docutils literal notranslate"><span class="pre">Compile</span></code> - will sport a <code class="docutils literal notranslate"><span class="pre">__call__</span></code> method which will act much like the builtin “compile” of 2.1 with the difference that after it has compiled a <code class="docutils literal notranslate"><span class="pre">__future__</span></code> statement, it “remembers” it and compiles all subsequent code with the <code class="docutils literal notranslate"><span class="pre">__future__</span></code> option in effect.</p> <p>It will do this by using the new features of the <code class="docutils literal notranslate"><span class="pre">__future__</span></code> module mentioned above.</p> <p>Objects of the other class added to codeop - <code class="docutils literal notranslate"><span class="pre">CommandCompiler</span></code> - will do the job of the existing <code class="docutils literal notranslate"><span class="pre">codeop.compile_command</span></code> function, but in a <code class="docutils literal notranslate"><span class="pre">__future__</span></code>-aware way.</p> <p>Finally, I propose to modify the class <code class="docutils literal notranslate"><span class="pre">InteractiveInterpreter</span></code> in the standard library module code to use a <code class="docutils literal notranslate"><span class="pre">CommandCompiler</span></code> to emulate still more closely the behaviour of the default Python shell.</p> </section> <section id="backward-compatibility"> <h2><a class="toc-backref" href="#backward-compatibility" role="doc-backlink">Backward Compatibility</a></h2> <p>Should be very few or none; the changes to compile will make no difference to existing code, nor will adding new functions or classes to codeop. Existing code using <code class="docutils literal notranslate"><span class="pre">code.InteractiveInterpreter</span></code> may change in behaviour, but only for the better in that the “real” Python shell will be being better impersonated.</p> </section> <section id="forward-compatibility"> <h2><a class="toc-backref" href="#forward-compatibility" role="doc-backlink">Forward Compatibility</a></h2> <p>The fiddling that needs to be done to <code class="docutils literal notranslate"><span class="pre">Lib/__future__.py</span></code> when adding a <code class="docutils literal notranslate"><span class="pre">__future__</span></code> feature will be a touch more complicated. Everything else should just work.</p> </section> <section id="issues"> <h2><a class="toc-backref" href="#issues" role="doc-backlink">Issues</a></h2> <p>I hope the above interface is not too disruptive to implement for Jython.</p> </section> <section id="implementation"> <h2><a class="toc-backref" href="#implementation" role="doc-backlink">Implementation</a></h2> <p>A series of preliminary implementations are at <a class="footnote-reference brackets" href="#id2" id="id1">[1]</a>.</p> <p>After light massaging by Tim Peters, they have now been checked in.</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/tracker/?func=detail&atid=305470&aid=449043&group_id=5470">http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470</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-0264.rst">https://github.com/python/peps/blob/main/peps/pep-0264.rst</a></p> <p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0264.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="#specification">Specification</a></li> <li><a class="reference internal" href="#backward-compatibility">Backward Compatibility</a></li> <li><a class="reference internal" href="#forward-compatibility">Forward Compatibility</a></li> <li><a class="reference internal" href="#issues">Issues</a></li> <li><a class="reference internal" href="#implementation">Implementation</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-0264.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>