This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Improved range syntax
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.8
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Solomon Ucko, benjamin.peterson, brett.cannon, rhettinger, steven.daprano, yselivanov
Priority: normal Keywords:

Created on 2018-12-24 03:54 by Solomon Ucko, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (3)
msg332403 - (view) Author: Solomon Ucko (Solomon Ucko) Date: 2018-12-24 03:54
3 independent but related proposals. (#4 requires #3.) The main issue for #2 and #4 is the readability of a mix of square and round brackets, especially within nested brackets. This would be less of an issue with [Coconut support](

#1. Range inclusive/exclusive keyword arguments (mostly backward compatible)

Inclusive/exclusive options for range as keyword arguments (defaulting to `inc_start=True, inc_stop=False`). Code that processes range objects will ignore these unless using `in` tests. The semantics would be as follows:

class range:
    def __iter__(self):
        if self.inc_start:
            yield self.start
        i = self.start + self.step
        while i < self.stop if self.step > 0 else i > self.stop:
            yield i
            i += self.step
        if self.inc_stop and i == self.stop:
            yield i

This would allow for control over the slightly controversial decision of inclusivity/exclusivity for ranges on a case-by-case basis. Any existing code that creates ranges would not be impacted.

#2. Range syntax (fully backward compatible)

Maybe `(start:stop)`, `(start:stop]`, `[start:stop)` and `[start:stop]` could be used to represent ranges? (`(` = exclusive; `[` = inclusive.) Step notation would also be legal. (E.g. `(start:stop:step)`.)

This would allow for a concise, familiar notation for ranges.

#3. Slice inclusive/exclusive keyword arguments (mostly backward compatible)

This is analogous to #1, except with `slice` instead of `range`.

#4. Slice inclusive/exclusive syntax (would require a __future__ in Python 3)

As opposed to forcing half-open intervals, a mix of round parentheses and square brackets could be allowed to be used for slices, analogously to #2. Since square brackets with a colon currently represent half-open intervals, this would have to require a __future__ import in Python 3. This could become the default in Python 4.
msg332417 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2018-12-24 06:37
These proposals probably should be discussed on Python-Ideas first. You should also familiarize yourself with previous proposals to enhance range, such as

and the bug report #35200

For what it is worth, Guido was generally (slightly) opposed to "constant bool parameters", functions that take a parameter which is generally given as a literal True/False flag. That's often (not always) a design smell. I agree with him, so I would be very wary about adding not one but two such constant bool parameters.

Especially for such a trivial enhancement. There's nothing in the `inc_start=True, inc_stop=False` functionality which can't be more easily done by simply adding one to the appropriate range arguments:

    # same as inc_start=False, inc_stop=True but easier
    range(start+1, end+1)  

You say:

"a mix of round parentheses and square brackets could be allowed"

but I think such a proposal would run foul of the requirement that Python's grammar be no more complex than LL(1). 

(Someone will correct me if I'm wrong.)
msg332421 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-12-24 08:06
A Steven noted, this will need to go to Python ideas.  FWIW, there are a number of rejected PEPs on this subject.  Please have a look at those to see what has been previously discusses and decided.
Date User Action Args
2022-04-11 14:59:09adminsetgithub: 79756
2018-12-24 08:06:31rhettingersetstatus: open -> closed

nosy: + rhettinger
messages: + msg332421

resolution: rejected
stage: resolved
2018-12-24 06:37:50steven.dapranosetnosy: + steven.daprano
messages: + msg332417
2018-12-24 03:54:19Solomon Uckocreate