313 lines
20 KiB
HTML
313 lines
20 KiB
HTML
|
||
<!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 3099 – Things that will Not Change in Python 3000 | peps.python.org</title>
|
||
<link rel="shortcut icon" href="../_static/py.png">
|
||
<link rel="canonical" href="https://peps.python.org/pep-3099/">
|
||
<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 3099 – Things that will Not Change in Python 3000 | peps.python.org'>
|
||
<meta property="og:description" content="Some ideas are just bad. While some thoughts on Python evolution are constructive, some go against the basic tenets of Python so egregiously that it would be like asking someone to run in a circle: it gets you nowhere, even for Python 3000, where extra...">
|
||
<meta property="og:type" content="website">
|
||
<meta property="og:url" content="https://peps.python.org/pep-3099/">
|
||
<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="Some ideas are just bad. While some thoughts on Python evolution are constructive, some go against the basic tenets of Python so egregiously that it would be like asking someone to run in a circle: it gets you nowhere, even for Python 3000, where extra...">
|
||
<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 3099</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 3099 – Things that will Not Change in Python 3000</h1>
|
||
<dl class="rfc2822 field-list simple">
|
||
<dt class="field-odd">Author<span class="colon">:</span></dt>
|
||
<dd class="field-odd">Georg Brandl <georg 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 describing or proposing a change to a Python community process, workflow or governance">Process</abbr></dd>
|
||
<dt class="field-even">Created<span class="colon">:</span></dt>
|
||
<dd class="field-even">04-Apr-2006</dd>
|
||
<dt class="field-odd">Post-History<span class="colon">:</span></dt>
|
||
<dd class="field-odd"><p></p></dd>
|
||
</dl>
|
||
<hr class="docutils" />
|
||
<section id="contents">
|
||
<details><summary>Table of Contents</summary><ul class="simple">
|
||
<li><a class="reference internal" href="#abstract">Abstract</a></li>
|
||
<li><a class="reference internal" href="#core-language">Core language</a></li>
|
||
<li><a class="reference internal" href="#builtins">Builtins</a></li>
|
||
<li><a class="reference internal" href="#standard-types">Standard types</a></li>
|
||
<li><a class="reference internal" href="#coding-style">Coding style</a></li>
|
||
<li><a class="reference internal" href="#interactive-interpreter">Interactive Interpreter</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>Some ideas are just bad. While some thoughts on Python evolution are
|
||
constructive, some go against the basic tenets of Python so
|
||
egregiously that it would be like asking someone to run in a circle:
|
||
it gets you nowhere, even for Python 3000, where extraordinary
|
||
proposals are allowed. This PEP tries to list all BDFL pronouncements
|
||
on Python 3000 that refer to changes that will not happen and new
|
||
features that will not be introduced, sorted by topics, along with
|
||
a short explanation or a reference to the relevant thread on the
|
||
python-3000 mailing list.</p>
|
||
<p>If you think you should suggest any of the listed ideas it would be
|
||
better to just step away from the computer, go outside, and enjoy
|
||
yourself. Being active outdoors by napping in a nice patch of grass
|
||
is more productive than bringing up a beating-a-dead-horse idea and
|
||
having people tell you how dead the idea is. Consider yourself warned.</p>
|
||
</section>
|
||
<section id="core-language">
|
||
<h2><a class="toc-backref" href="#core-language" role="doc-backlink">Core language</a></h2>
|
||
<ul>
|
||
<li>Python 3000 will not be case-insensitive.</li>
|
||
<li>Python 3000 will not be a rewrite from scratch.<blockquote>
|
||
<div>It will also not use C++ or another language different from C
|
||
as implementation language. Rather, there will be a gradual
|
||
transmogrification of the codebase. There’s an excellent essay
|
||
by Joel Spolsky explaining why:
|
||
<a class="reference external" href="http://www.joelonsoftware.com/articles/fog0000000069.html">http://www.joelonsoftware.com/articles/fog0000000069.html</a></div></blockquote>
|
||
</li>
|
||
<li><code class="docutils literal notranslate"><span class="pre">self</span></code> will not become implicit.<blockquote>
|
||
<div>Having <code class="docutils literal notranslate"><span class="pre">self</span></code> be explicit is a <em>good thing</em>. It makes the code
|
||
clear by removing ambiguity about how a variable resolves. It also
|
||
makes the difference between functions and methods small.<p>Thread: “Draft proposal: Implicit self in Python 3.0”
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-dev/2006-January/059468.html">https://mail.python.org/pipermail/python-dev/2006-January/059468.html</a></p>
|
||
</div></blockquote>
|
||
</li>
|
||
<li><code class="docutils literal notranslate"><span class="pre">lambda</span></code> will not be renamed.<blockquote>
|
||
<div>At one point lambda was slated for removal in Python 3000.
|
||
Unfortunately no one was able to come up with a better way of
|
||
providing anonymous functions. And so lambda is here to stay.<p>But it is here to stay as-is. Adding support for statements is a
|
||
non-starter. It would require allowing multi-line lambda
|
||
expressions which would mean a multi-line expression could suddenly
|
||
exist. That would allow for multi-line arguments to function
|
||
calls, for instance. That is just plain ugly.</p>
|
||
<p>Thread: “genexp syntax / lambda”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-April/001042.html">https://mail.python.org/pipermail/python-3000/2006-April/001042.html</a></p>
|
||
</div></blockquote>
|
||
</li>
|
||
<li>Python will not have programmable syntax.<blockquote>
|
||
<div>Thread: “It’s a statement! It’s a function! It’s BOTH!”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-April/000286.html">https://mail.python.org/pipermail/python-3000/2006-April/000286.html</a></div></blockquote>
|
||
</li>
|
||
<li>There won’t be a syntax for <code class="docutils literal notranslate"><span class="pre">zip()</span></code>-style parallel iteration.<blockquote>
|
||
<div>Thread: “Parallel iteration syntax”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-March/000210.html">https://mail.python.org/pipermail/python-3000/2006-March/000210.html</a></div></blockquote>
|
||
</li>
|
||
<li>Strings will stay iterable.<blockquote>
|
||
<div>Thread: “Making strings non-iterable”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-April/000759.html">https://mail.python.org/pipermail/python-3000/2006-April/000759.html</a></div></blockquote>
|
||
</li>
|
||
<li>There will be no syntax to sort the result of a generator expression
|
||
or list comprehension. <code class="docutils literal notranslate"><span class="pre">sorted()</span></code> covers all use cases.<blockquote>
|
||
<div>Thread: “Adding sorting to generator comprehension”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-April/001295.html">https://mail.python.org/pipermail/python-3000/2006-April/001295.html</a></div></blockquote>
|
||
</li>
|
||
<li>Slices and extended slices won’t go away (even if the __getslice__
|
||
and __setslice__ APIs may be replaced) nor will they return views
|
||
for the standard object types.<blockquote>
|
||
<div>Thread: Future of slices
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-May/001563.html">https://mail.python.org/pipermail/python-3000/2006-May/001563.html</a></div></blockquote>
|
||
</li>
|
||
<li>It will not be forbidden to reuse a loop variable inside the loop’s
|
||
suite.<blockquote>
|
||
<div>Thread: elimination of scope bleeding of iteration variables
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-dev/2006-May/064761.html">https://mail.python.org/pipermail/python-dev/2006-May/064761.html</a></div></blockquote>
|
||
</li>
|
||
<li>The parser won’t be more complex than LL(1).<blockquote>
|
||
<div>Simple is better than complex. This idea extends to the parser.
|
||
Restricting Python’s grammar to an LL(1) parser is a blessing,
|
||
not a curse. It puts us in handcuffs that prevent us from going
|
||
overboard and ending up with funky grammar rules like some other
|
||
dynamic languages that will go unnamed, such as Perl.</div></blockquote>
|
||
</li>
|
||
<li>No braces.<blockquote>
|
||
<div>This is so obvious that it doesn’t need a reference to a mailing
|
||
list. Do <code class="docutils literal notranslate"><span class="pre">from</span> <span class="pre">__future__</span> <span class="pre">import</span> <span class="pre">braces</span></code> to get a definitive
|
||
answer on this subject.</div></blockquote>
|
||
</li>
|
||
<li>No more backticks.<blockquote>
|
||
<div>Backticks (`) will no longer be used as shorthand for <code class="docutils literal notranslate"><span class="pre">repr</span></code> –
|
||
but that doesn’t mean they are available for other uses. Even
|
||
ignoring the backwards compatibility confusion, the character
|
||
itself causes too many problems (in some fonts, on some keyboards,
|
||
when typesetting a book, etc).<p>Thread: “new operators via backquoting”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-ideas/2007-January/000054.html">https://mail.python.org/pipermail/python-ideas/2007-January/000054.html</a></p>
|
||
</div></blockquote>
|
||
</li>
|
||
<li>Referencing the global name <code class="docutils literal notranslate"><span class="pre">foo</span></code> will not be spelled <code class="docutils literal notranslate"><span class="pre">globals.foo</span></code>.
|
||
The <code class="docutils literal notranslate"><span class="pre">global</span></code> statement will stay.<blockquote>
|
||
<div>Threads: “replace globals() and global statement with global builtin
|
||
object”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-July/002485.html">https://mail.python.org/pipermail/python-3000/2006-July/002485.html</a>,
|
||
“Explicit Lexical Scoping (pre-PEP?)”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-dev/2006-July/067111.html">https://mail.python.org/pipermail/python-dev/2006-July/067111.html</a></div></blockquote>
|
||
</li>
|
||
<li>There will be no alternative binding operators such as <code class="docutils literal notranslate"><span class="pre">:=</span></code>.<blockquote>
|
||
<div>Thread: “Explicit Lexical Scoping (pre-PEP?)”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-dev/2006-July/066995.html">https://mail.python.org/pipermail/python-dev/2006-July/066995.html</a></div></blockquote>
|
||
</li>
|
||
<li>We won’t be removing container literals.
|
||
That is, {expr: expr, …}, [expr, …] and (expr, …) will stay.<blockquote>
|
||
<div>Thread: “No Container Literals”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-July/002550.html">https://mail.python.org/pipermail/python-3000/2006-July/002550.html</a></div></blockquote>
|
||
</li>
|
||
<li>The <code class="docutils literal notranslate"><span class="pre">else</span></code> clause in <code class="docutils literal notranslate"><span class="pre">while</span></code> and <code class="docutils literal notranslate"><span class="pre">for</span></code> loops will not change
|
||
semantics, or be removed.<blockquote>
|
||
<div>Thread: “for/except/else syntax”
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-ideas/2009-October/006083.html">https://mail.python.org/pipermail/python-ideas/2009-October/006083.html</a></div></blockquote>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
<section id="builtins">
|
||
<h2><a class="toc-backref" href="#builtins" role="doc-backlink">Builtins</a></h2>
|
||
<ul>
|
||
<li><code class="docutils literal notranslate"><span class="pre">zip()</span></code> won’t grow keyword arguments or other mechanisms to prevent
|
||
it from stopping at the end of the shortest sequence.<blockquote>
|
||
<div>Thread: “have zip() raise exception for sequences of different lengths”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-August/003338.html">https://mail.python.org/pipermail/python-3000/2006-August/003338.html</a></div></blockquote>
|
||
</li>
|
||
<li><code class="docutils literal notranslate"><span class="pre">hash()</span></code> won’t become an attribute since attributes should be cheap
|
||
to compute, which isn’t necessarily the case for a hash.<blockquote>
|
||
<div>Thread: “hash as attribute/property”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-April/000362.html">https://mail.python.org/pipermail/python-3000/2006-April/000362.html</a></div></blockquote>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
<section id="standard-types">
|
||
<h2><a class="toc-backref" href="#standard-types" role="doc-backlink">Standard types</a></h2>
|
||
<ul>
|
||
<li>Iterating over a dictionary will continue to yield the keys.<blockquote>
|
||
<div>Thread: “Iterating over a dict”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-April/000283.html">https://mail.python.org/pipermail/python-3000/2006-April/000283.html</a><p>Thread: have iter(mapping) generate (key, value) pairs
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-June/002368.html">https://mail.python.org/pipermail/python-3000/2006-June/002368.html</a></p>
|
||
</div></blockquote>
|
||
</li>
|
||
<li>There will be no <code class="docutils literal notranslate"><span class="pre">frozenlist</span></code> type.<blockquote>
|
||
<div>Thread: “Immutable lists”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-May/002219.html">https://mail.python.org/pipermail/python-3000/2006-May/002219.html</a></div></blockquote>
|
||
</li>
|
||
<li><code class="docutils literal notranslate"><span class="pre">int</span></code> will not support subscripts yielding a range.<blockquote>
|
||
<div>Thread: “xrange vs. int.__getslice__”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-June/002450.html">https://mail.python.org/pipermail/python-3000/2006-June/002450.html</a></div></blockquote>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
<section id="coding-style">
|
||
<h2><a class="toc-backref" href="#coding-style" role="doc-backlink">Coding style</a></h2>
|
||
<ul>
|
||
<li>The (recommended) maximum line width will remain 80 characters,
|
||
for both C and Python code.<blockquote>
|
||
<div>Thread: “C style guide”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-March/000131.html">https://mail.python.org/pipermail/python-3000/2006-March/000131.html</a></div></blockquote>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
<section id="interactive-interpreter">
|
||
<h2><a class="toc-backref" href="#interactive-interpreter" role="doc-backlink">Interactive Interpreter</a></h2>
|
||
<ul>
|
||
<li>The interpreter prompt (<code class="docutils literal notranslate"><span class="pre">>>></span></code>) will not change. It gives Guido warm
|
||
fuzzy feelings.<blockquote>
|
||
<div>Thread: “Low-hanging fruit: change interpreter prompt?”,
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-November/004891.html">https://mail.python.org/pipermail/python-3000/2006-November/004891.html</a></div></blockquote>
|
||
</li>
|
||
</ul>
|
||
</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-3099.rst">https://github.com/python/peps/blob/main/peps/pep-3099.rst</a></p>
|
||
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-3099.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="#core-language">Core language</a></li>
|
||
<li><a class="reference internal" href="#builtins">Builtins</a></li>
|
||
<li><a class="reference internal" href="#standard-types">Standard types</a></li>
|
||
<li><a class="reference internal" href="#coding-style">Coding style</a></li>
|
||
<li><a class="reference internal" href="#interactive-interpreter">Interactive Interpreter</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-3099.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> |