402 lines
29 KiB
HTML
402 lines
29 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 204 – Range Literals | peps.python.org</title>
|
||
<link rel="shortcut icon" href="../_static/py.png">
|
||
<link rel="canonical" href="https://peps.python.org/pep-0204/">
|
||
<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 204 – Range Literals | peps.python.org'>
|
||
<meta property="og:description" content="This PEP describes the “range literal” proposal for Python 2.0. This PEP tracks the status and ownership of this feature, slated for introduction in Python 2.0. It contains a description of the feature and outlines changes necessary to support the feat...">
|
||
<meta property="og:type" content="website">
|
||
<meta property="og:url" content="https://peps.python.org/pep-0204/">
|
||
<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 “range literal” proposal for Python 2.0. This PEP tracks the status and ownership of this feature, slated for introduction in Python 2.0. It contains a description of the feature and outlines changes necessary to support the feat...">
|
||
<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 204</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 204 – Range Literals</h1>
|
||
<dl class="rfc2822 field-list simple">
|
||
<dt class="field-odd">Author<span class="colon">:</span></dt>
|
||
<dd class="field-odd">Thomas Wouters <thomas at python.org></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">14-Jul-2000</dd>
|
||
<dt class="field-odd">Python-Version<span class="colon">:</span></dt>
|
||
<dd class="field-odd">2.0</dd>
|
||
<dt class="field-even">Post-History<span class="colon">:</span></dt>
|
||
<dd class="field-even"><p></p></dd>
|
||
</dl>
|
||
<hr class="docutils" />
|
||
<section id="contents">
|
||
<details><summary>Table of Contents</summary><ul class="simple">
|
||
<li><a class="reference internal" href="#introduction">Introduction</a></li>
|
||
<li><a class="reference internal" href="#list-ranges">List ranges</a></li>
|
||
<li><a class="reference internal" href="#slice-indices">Slice Indices</a></li>
|
||
<li><a class="reference internal" href="#the-proposed-solution">The Proposed Solution</a></li>
|
||
<li><a class="reference internal" href="#reference-implementation">Reference Implementation</a></li>
|
||
<li><a class="reference internal" href="#open-issues">Open issues</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>After careful consideration, and a period of meditation, this
|
||
proposal has been rejected. The open issues, as well as some
|
||
confusion between ranges and slice syntax, raised enough questions
|
||
for Guido not to accept it for Python 2.0, and later to reject the
|
||
proposal altogether. The new syntax and its intentions were deemed
|
||
not obvious enough.</p>
|
||
<p>[ TBD: Guido, amend/confirm this, please. Preferably both; this
|
||
is a PEP, it should contain <em>all</em> the reasons for rejection
|
||
and/or reconsideration, for future reference. ]</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 “range literal” proposal for Python 2.0.
|
||
This PEP tracks the status and ownership of this feature, slated
|
||
for introduction in Python 2.0. It contains a description of the
|
||
feature and outlines changes necessary to support the feature.
|
||
This PEP summarizes discussions held in mailing list forums, and
|
||
provides URLs for further information, where appropriate. The CVS
|
||
revision history of this file contains the definitive historical
|
||
record.</p>
|
||
</section>
|
||
<section id="list-ranges">
|
||
<h2><a class="toc-backref" href="#list-ranges" role="doc-backlink">List ranges</a></h2>
|
||
<p>Ranges are sequences of numbers of a fixed stepping, often used in
|
||
for-loops. The Python for-loop is designed to iterate over a
|
||
sequence directly:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="n">l</span> <span class="o">=</span> <span class="p">[</span><span class="s1">'a'</span><span class="p">,</span> <span class="s1">'b'</span><span class="p">,</span> <span class="s1">'c'</span><span class="p">,</span> <span class="s1">'d'</span><span class="p">]</span>
|
||
<span class="gp">>>> </span><span class="k">for</span> <span class="n">item</span> <span class="ow">in</span> <span class="n">l</span><span class="p">:</span>
|
||
<span class="gp">... </span> <span class="nb">print</span> <span class="n">item</span>
|
||
<span class="go">a</span>
|
||
<span class="go">b</span>
|
||
<span class="go">c</span>
|
||
<span class="go">d</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>However, this solution is not always prudent. Firstly, problems
|
||
arise when altering the sequence in the body of the for-loop,
|
||
resulting in the for-loop skipping items. Secondly, it is not
|
||
possible to iterate over, say, every second element of the
|
||
sequence. And thirdly, it is sometimes necessary to process an
|
||
element based on its index, which is not readily available in the
|
||
above construct.</p>
|
||
<p>For these instances, and others where a range of numbers is
|
||
desired, Python provides the <code class="docutils literal notranslate"><span class="pre">range</span></code> builtin function, which
|
||
creates a list of numbers. The <code class="docutils literal notranslate"><span class="pre">range</span></code> function takes three
|
||
arguments, <em>start</em>, <em>end</em> and <em>step</em>. <em>start</em> and <em>step</em> are
|
||
optional, and default to 0 and 1, respectively.</p>
|
||
<p>The <code class="docutils literal notranslate"><span class="pre">range</span></code> function creates a list of numbers, starting at
|
||
<em>start</em>, with a step of <em>step</em>, up to, but not including <em>end</em>, so
|
||
that <code class="docutils literal notranslate"><span class="pre">range(10)</span></code> produces a list that has exactly 10 items, the
|
||
numbers 0 through 9.</p>
|
||
<p>Using the <code class="docutils literal notranslate"><span class="pre">range</span></code> function, the above example would look like
|
||
this:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="k">for</span> <span class="n">i</span> <span class="ow">in</span> <span class="nb">range</span><span class="p">(</span><span class="nb">len</span><span class="p">(</span><span class="n">l</span><span class="p">)):</span>
|
||
<span class="gp">... </span> <span class="nb">print</span> <span class="n">l</span><span class="p">[</span><span class="n">i</span><span class="p">]</span>
|
||
<span class="go">a</span>
|
||
<span class="go">b</span>
|
||
<span class="go">c</span>
|
||
<span class="go">d</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Or, to start at the second element of <code class="docutils literal notranslate"><span class="pre">l</span></code> and processing only
|
||
every second element from then on:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="k">for</span> <span class="n">i</span> <span class="ow">in</span> <span class="nb">range</span><span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="nb">len</span><span class="p">(</span><span class="n">l</span><span class="p">),</span> <span class="mi">2</span><span class="p">):</span>
|
||
<span class="gp">... </span> <span class="nb">print</span> <span class="n">l</span><span class="p">[</span><span class="n">i</span><span class="p">]</span>
|
||
<span class="go">b</span>
|
||
<span class="go">d</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>There are several disadvantages with this approach:</p>
|
||
<ul class="simple">
|
||
<li>Clarity of purpose: Adding another function call, possibly with
|
||
extra arithmetic to determine the desired length and step of the
|
||
list, does not improve readability of the code. Also, it is
|
||
possible to “shadow” the builtin <code class="docutils literal notranslate"><span class="pre">range</span></code> function by supplying a
|
||
local or global variable with the same name, effectively
|
||
replacing it. This may or may not be a desired effect.</li>
|
||
<li>Efficiency: because the <code class="docutils literal notranslate"><span class="pre">range</span></code> function can be overridden, the
|
||
Python compiler cannot make assumptions about the for-loop, and
|
||
has to maintain a separate loop counter.</li>
|
||
<li>Consistency: There already is a syntax that is used to denote
|
||
ranges, as shown below. This syntax uses the exact same
|
||
arguments, though all optional, in the exact same way. It seems
|
||
logical to extend this syntax to ranges, to form “range
|
||
literals”.</li>
|
||
</ul>
|
||
</section>
|
||
<section id="slice-indices">
|
||
<h2><a class="toc-backref" href="#slice-indices" role="doc-backlink">Slice Indices</a></h2>
|
||
<p>In Python, a sequence can be indexed in one of two ways:
|
||
retrieving a single item, or retrieving a range of items.
|
||
Retrieving a range of items results in a new object of the same
|
||
type as the original sequence, containing zero or more items from
|
||
the original sequence. This is done using a “range notation”:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="n">l</span><span class="p">[</span><span class="mi">2</span><span class="p">:</span><span class="mi">4</span><span class="p">]</span>
|
||
<span class="go">['c', 'd']</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>This range notation consists of zero, one or two indices separated
|
||
by a colon. The first index is the <em>start</em> index, the second the
|
||
<em>end</em>. When either is left out, they default to respectively the
|
||
start and the end of the sequence.</p>
|
||
<p>There is also an extended range notation, which incorporates
|
||
<em>step</em> as well. Though this notation is not currently supported
|
||
by most builtin types, if it were, it would work as follows:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="n">l</span><span class="p">[</span><span class="mi">1</span><span class="p">:</span><span class="mi">4</span><span class="p">:</span><span class="mi">2</span><span class="p">]</span>
|
||
<span class="go">['b', 'd']</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The third “argument” to the slice syntax is exactly the same as
|
||
the <em>step</em> argument to <code class="docutils literal notranslate"><span class="pre">range()</span></code>. The underlying mechanisms of the
|
||
standard, and these extended slices, are sufficiently different
|
||
and inconsistent that many classes and extensions outside of
|
||
mathematical packages do not implement support for the extended
|
||
variant. While this should be resolved, it is beyond the scope of
|
||
this PEP.</p>
|
||
<p>Extended slices do show, however, that there is already a
|
||
perfectly valid and applicable syntax to denote ranges in a way
|
||
that solve all of the earlier stated disadvantages of the use of
|
||
the <code class="docutils literal notranslate"><span class="pre">range()</span></code> function:</p>
|
||
<ul class="simple">
|
||
<li>It is clearer, more concise syntax, which has already proven to
|
||
be both intuitive and easy to learn.</li>
|
||
<li>It is consistent with the other use of ranges in Python
|
||
(e.g. slices).</li>
|
||
<li>Because it is built-in syntax, instead of a builtin function, it
|
||
cannot be overridden. This means both that a viewer can be
|
||
certain about what the code does, and that an optimizer will not
|
||
have to worry about <code class="docutils literal notranslate"><span class="pre">range()</span></code> being “shadowed”.</li>
|
||
</ul>
|
||
</section>
|
||
<section id="the-proposed-solution">
|
||
<h2><a class="toc-backref" href="#the-proposed-solution" role="doc-backlink">The Proposed Solution</a></h2>
|
||
<p>The proposed implementation of range-literals combines the syntax
|
||
for list literals with the syntax for (extended) slices, to form
|
||
range literals:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="p">[</span><span class="mi">1</span><span class="p">:</span><span class="mi">10</span><span class="p">]</span>
|
||
<span class="go">[1, 2, 3, 4, 5, 6, 7, 8, 9]</span>
|
||
<span class="gp">>>> </span><span class="p">[:</span><span class="mi">5</span><span class="p">]</span>
|
||
<span class="go">[0, 1, 2, 3, 4]</span>
|
||
<span class="gp">>>> </span><span class="p">[</span><span class="mi">5</span><span class="p">:</span><span class="mi">1</span><span class="p">:</span><span class="o">-</span><span class="mi">1</span><span class="p">]</span>
|
||
<span class="go">[5, 4, 3, 2]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>There is one minor difference between range literals and the slice
|
||
syntax: though it is possible to omit all of <em>start</em>, <em>end</em> and
|
||
<em>step</em> in slices, it does not make sense to omit <em>end</em> in range
|
||
literals. In slices, <em>end</em> would default to the end of the list,
|
||
but this has no meaning in range literals.</p>
|
||
</section>
|
||
<section id="reference-implementation">
|
||
<h2><a class="toc-backref" href="#reference-implementation" role="doc-backlink">Reference Implementation</a></h2>
|
||
<p>The proposed implementation can be found on SourceForge <a class="footnote-reference brackets" href="#id2" id="id1">[1]</a>. It
|
||
adds a new bytecode, <code class="docutils literal notranslate"><span class="pre">BUILD_RANGE</span></code>, that takes three arguments from
|
||
the stack and builds a list on the bases of those. The list is
|
||
pushed back on the stack.</p>
|
||
<p>The use of a new bytecode is necessary to be able to build ranges
|
||
based on other calculations, whose outcome is not known at compile
|
||
time.</p>
|
||
<p>The code introduces two new functions to <code class="docutils literal notranslate"><span class="pre">listobject.c</span></code>, which are
|
||
currently hovering between private functions and full-fledged API
|
||
calls.</p>
|
||
<p><code class="docutils literal notranslate"><span class="pre">PyList_FromRange()</span></code> builds a list from start, end and step,
|
||
returning NULL if an error occurs. Its prototype is:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">PyObject</span> <span class="o">*</span> <span class="n">PyList_FromRange</span><span class="p">(</span><span class="n">long</span> <span class="n">start</span><span class="p">,</span> <span class="n">long</span> <span class="n">end</span><span class="p">,</span> <span class="n">long</span> <span class="n">step</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p><code class="docutils literal notranslate"><span class="pre">PyList_GetLenOfRange()</span></code> is a helper function used to determine the
|
||
length of a range. Previously, it was a static function in
|
||
<code class="docutils literal notranslate"><span class="pre">bltinmodule.c</span></code>, but is now necessary in both <code class="docutils literal notranslate"><span class="pre">listobject.c</span></code> and
|
||
<code class="docutils literal notranslate"><span class="pre">bltinmodule.c</span></code> (for <code class="docutils literal notranslate"><span class="pre">xrange</span></code>). It is made non-static solely to avoid
|
||
code duplication. Its prototype is:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">long</span> <span class="n">PyList_GetLenOfRange</span><span class="p">(</span><span class="n">long</span> <span class="n">start</span><span class="p">,</span> <span class="n">long</span> <span class="n">end</span><span class="p">,</span> <span class="n">long</span> <span class="n">step</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
</section>
|
||
<section id="open-issues">
|
||
<h2><a class="toc-backref" href="#open-issues" role="doc-backlink">Open issues</a></h2>
|
||
<ul>
|
||
<li>One possible solution to the discrepancy of requiring the <em>end</em>
|
||
argument in range literals is to allow the range syntax to
|
||
create a “generator”, rather than a list, such as the <code class="docutils literal notranslate"><span class="pre">xrange</span></code>
|
||
builtin function does. However, a generator would not be a
|
||
list, and it would be impossible, for instance, to assign to
|
||
items in the generator, or append to it.<p>The range syntax could conceivably be extended to include tuples
|
||
(i.e. immutable lists), which could then be safely implemented
|
||
as generators. This may be a desirable solution, especially for
|
||
large number arrays: generators require very little in the way
|
||
of storage and initialization, and there is only a small
|
||
performance impact in calculating and creating the appropriate
|
||
number on request. (TBD: is there any at all? Cursory testing
|
||
suggests equal performance even in the case of ranges of length
|
||
1)</p>
|
||
<p>However, even if idea was adopted, would it be wise to “special
|
||
case” the second argument, making it optional in one instance of
|
||
the syntax, and non-optional in other cases ?</p>
|
||
</li>
|
||
<li>Should it be possible to mix range syntax with normal list
|
||
literals, creating a single list? E.g.:<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="p">[</span><span class="mi">5</span><span class="p">,</span> <span class="mi">6</span><span class="p">,</span> <span class="mi">1</span><span class="p">:</span><span class="mi">6</span><span class="p">,</span> <span class="mi">7</span><span class="p">,</span> <span class="mi">9</span><span class="p">]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>to create:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">[</span><span class="mi">5</span><span class="p">,</span> <span class="mi">6</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">,</span> <span class="mi">4</span><span class="p">,</span> <span class="mi">5</span><span class="p">,</span> <span class="mi">7</span><span class="p">,</span> <span class="mi">9</span><span class="p">]</span>
|
||
</pre></div>
|
||
</div>
|
||
</li>
|
||
<li>How should range literals interact with another proposed new
|
||
feature, <a class="pep reference internal" href="../pep-0202/" title="PEP 202 – List Comprehensions">“list comprehensions”</a>? Specifically, should it be
|
||
possible to create lists in list comprehensions? E.g.:<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="p">[</span><span class="n">x</span><span class="p">:</span><span class="n">y</span> <span class="k">for</span> <span class="n">x</span> <span class="ow">in</span> <span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">)</span> <span class="n">y</span> <span class="ow">in</span> <span class="p">(</span><span class="mi">3</span><span class="p">,</span> <span class="mi">4</span><span class="p">)]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Should this example return a single list with multiple ranges:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">[</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Or a list of lists, like so:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">[[</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">],</span> <span class="p">[</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">],</span> <span class="p">[</span><span class="mi">2</span><span class="p">],</span> <span class="p">[</span><span class="mi">2</span><span class="p">,</span> <span class="mi">3</span><span class="p">]]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>However, as the syntax and semantics of list comprehensions are
|
||
still subject of hot debate, these issues are probably best
|
||
addressed by the “list comprehensions” PEP.</p>
|
||
</li>
|
||
<li>Range literals accept objects other than integers: it performs
|
||
<code class="docutils literal notranslate"><span class="pre">PyInt_AsLong()</span></code> on the objects passed in, so as long as the
|
||
objects can be coerced into integers, they will be accepted.
|
||
The resulting list, however, is always composed of standard
|
||
integers.<p>Should range literals create a list of the passed-in type? It
|
||
might be desirable in the cases of other builtin types, such as
|
||
longs and strings:</p>
|
||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="p">[</span> <span class="mi">1</span><span class="n">L</span> <span class="p">:</span> <span class="mi">2</span><span class="n">L</span><span class="o"><<</span><span class="mi">64</span> <span class="p">:</span> <span class="mi">2</span><span class="o"><<</span><span class="mi">32</span><span class="n">L</span> <span class="p">]</span>
|
||
<span class="gp">>>> </span><span class="p">[</span><span class="s2">"a"</span><span class="p">:</span><span class="s2">"z"</span><span class="p">:</span><span class="s2">"b"</span><span class="p">]</span>
|
||
<span class="gp">>>> </span><span class="p">[</span><span class="s2">"a"</span><span class="p">:</span><span class="s2">"z"</span><span class="p">:</span><span class="mi">2</span><span class="p">]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>However, this might be too much “magic” to be obvious. It might
|
||
also present problems with user-defined classes: even if the
|
||
base class can be found and a new instance created, the instance
|
||
may require additional arguments to <code class="docutils literal notranslate"><span class="pre">__init__</span></code>, causing the
|
||
creation to fail.</p>
|
||
</li>
|
||
<li>The <code class="docutils literal notranslate"><span class="pre">PyList_FromRange()</span></code> and <code class="docutils literal notranslate"><span class="pre">PyList_GetLenOfRange()</span></code> functions need
|
||
to be classified: are they part of the API, or should they be
|
||
made private functions?</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 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=100902&group_id=5470">http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&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-0204.rst">https://github.com/python/peps/blob/main/peps/pep-0204.rst</a></p>
|
||
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0204.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="#list-ranges">List ranges</a></li>
|
||
<li><a class="reference internal" href="#slice-indices">Slice Indices</a></li>
|
||
<li><a class="reference internal" href="#the-proposed-solution">The Proposed Solution</a></li>
|
||
<li><a class="reference internal" href="#reference-implementation">Reference Implementation</a></li>
|
||
<li><a class="reference internal" href="#open-issues">Open issues</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-0204.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> |