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 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> Toggle light / dark / auto colour theme </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:</dt> <dd class="field-odd">Thomas Wouters <thomas at python.org></dd> <dt class="field-even">Status:</dt> <dd class="field-even"><abbr title="Formally declined and will not be accepted">Rejected</abbr></dd> <dt class="field-odd">Type:</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:</dt> <dd class="field-even">14-Jul-2000</dd> <dt class="field-odd">Python-Version:</dt> <dd class="field-odd">2.0</dd> <dt class="field-even">Post-History:</dt> <dd class="field-even"></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"> Warning This PEP has been rejected. × 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. [ TBD: Guido, amend/confirm this, please. Preferably both; this is a PEP, it should contain all the reasons for rejection and/or reconsideration, for future reference. ] </div> <section id="introduction"> <h2><a class="toc-backref" href="#introduction" role="doc-backlink">Introduction</a></h2> 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. </section> <section id="list-ranges"> <h2><a class="toc-backref" href="#list-ranges" role="doc-backlink">List ranges</a></h2> 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: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> l = ['a', 'b', 'c', 'd'] >>> for item in l: ... print item a b c d </pre></div> </div> 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. For these instances, and others where a range of numbers is desired, Python provides the <code class="docutils literal notranslate">range</code> builtin function, which creates a list of numbers. The <code class="docutils literal notranslate">range</code> function takes three arguments, start, end and step. start and step are optional, and default to 0 and 1, respectively. The <code class="docutils literal notranslate">range</code> function creates a list of numbers, starting at start, with a step of step, up to, but not including end, so that <code class="docutils literal notranslate">range(10)</code> produces a list that has exactly 10 items, the numbers 0 through 9. Using the <code class="docutils literal notranslate">range</code> function, the above example would look like this: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> for i in range(len(l)): ... print l[i] a b c d </pre></div> </div> Or, to start at the second element of <code class="docutils literal notranslate">l</code> and processing only every second element from then on: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> for i in range(1, len(l), 2): ... print l[i] b d </pre></div> </div> There are several disadvantages with this approach: <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">range</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">range</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> 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”: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> l[2:4] ['c', 'd'] </pre></div> </div> This range notation consists of zero, one or two indices separated by a colon. The first index is the start index, the second the end. When either is left out, they default to respectively the start and the end of the sequence. There is also an extended range notation, which incorporates step as well. Though this notation is not currently supported by most builtin types, if it were, it would work as follows: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> l[1:4:2] ['b', 'd'] </pre></div> </div> The third “argument” to the slice syntax is exactly the same as the step argument to <code class="docutils literal notranslate">range()</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. 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">range()</code> function: <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">range()</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> The proposed implementation of range-literals combines the syntax for list literals with the syntax for (extended) slices, to form range literals: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> [1:10] [1, 2, 3, 4, 5, 6, 7, 8, 9] >>> [:5] [0, 1, 2, 3, 4] >>> [5:1:-1] [5, 4, 3, 2] </pre></div> </div> There is one minor difference between range literals and the slice syntax: though it is possible to omit all of start, end and step in slices, it does not make sense to omit end in range literals. In slices, end would default to the end of the list, but this has no meaning in range literals. </section> <section id="reference-implementation"> <h2><a class="toc-backref" href="#reference-implementation" role="doc-backlink">Reference Implementation</a></h2> 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">BUILD_RANGE</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. 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. The code introduces two new functions to <code class="docutils literal notranslate">listobject.c</code>, which are currently hovering between private functions and full-fledged API calls. <code class="docutils literal notranslate">PyList_FromRange()</code> builds a list from start, end and step, returning NULL if an error occurs. Its prototype is: <div class="highlight-default notranslate"><div class="highlight"><pre>PyObject * PyList_FromRange(long start, long end, long step) </pre></div> </div> <code class="docutils literal notranslate">PyList_GetLenOfRange()</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">bltinmodule.c</code>, but is now necessary in both <code class="docutils literal notranslate">listobject.c</code> and <code class="docutils literal notranslate">bltinmodule.c</code> (for <code class="docutils literal notranslate">xrange</code>). It is made non-static solely to avoid code duplication. Its prototype is: <div class="highlight-default notranslate"><div class="highlight"><pre>long PyList_GetLenOfRange(long start, long end, long step) </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 end 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">xrange</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.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) 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 ? </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>>>> [5, 6, 1:6, 7, 9] </pre></div> </div> to create: <div class="highlight-default notranslate"><div class="highlight"><pre>[5, 6, 1, 2, 3, 4, 5, 7, 9] </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>>>> [x:y for x in (1, 2) y in (3, 4)] </pre></div> </div> Should this example return a single list with multiple ranges: <div class="highlight-default notranslate"><div class="highlight"><pre>[1, 2, 1, 2, 3, 2, 2, 3] </pre></div> </div> Or a list of lists, like so: <div class="highlight-default notranslate"><div class="highlight"><pre>[[1, 2], [1, 2, 3], [2], [2, 3]] </pre></div> </div> 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. </li> <li>Range literals accept objects other than integers: it performs <code class="docutils literal notranslate">PyInt_AsLong()</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.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: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> [ 1L : 2L<<64 : 2<<32L ] >>> ["a":"z":"b"] >>> ["a":"z":2] </pre></div> </div> 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">__init__</code>, causing the creation to fail. </li> <li>The <code class="docutils literal notranslate">PyList_FromRange()</code> and <code class="docutils literal notranslate">PyList_GetLenOfRange()</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> This document has been placed in the Public Domain. </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" /> 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> 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> </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> <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>