[New-bugs-announce] [issue35575] Improved range syntax

[Solomon Ucko]

New submission from Solomon Ucko <solly.ucko at gmail.com>:

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](https://bugs.python.org/issue35574).

#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:

```python
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.

----------
components: Interpreter Core
messages: 332403
nosy: Solomon Ucko, benjamin.peterson, brett.cannon, yselivanov
priority: normal
severity: normal
status: open
title: Improved range syntax
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35575>
_______________________________________