Issue 35575: Improved range syntax (original) (raw)

Issue35575

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](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.
msg332417 - (view)	Author: Steven D'Aprano (steven.daprano) *	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 https://mail.python.org/pipermail/python-ideas/2018-November/054510.html 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) *	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.