Extend the range functionality to allow infinite ranges
Proposal: range(start, ..., step) should function like itertools.count(start, step) Reason: It's pretty common to see people do things where they increment a count within a while True loop, and it would be nice to have something easily available for people to use to replace this. Usefulness: There is definitely a use for this, as the type of code mentioned above is common, and itertools.count is commonly used as well.
How on earth is "count()" not easily available? On Fri, Jun 19, 2020 at 12:23 PM <kempr@edinburghacademy.org.uk> wrote:
-- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.
On Fri, Jun 19, 2020 at 12:25 PM <kempr@edinburghacademy.org.uk> wrote:
If the primary reason is usage in a for loop, why is itertools.count not already sufficient? --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
On Fri, Jun 19, 2020 at 12:29 PM Ricky Teachey <ricky@teachey.org> wrote:
Per my previous response, I don't find the reason given by the OP to be very convincing. However there's another possible reason to want to do this. I have more than once wanted to have infinite ranges that are analogous to infinite slices: slice(None) <=> range(0, infinity or perhaps None) slice(1, None) <=> range(1, infinity or perhaps None) slice(-1, None, -1) <=> range(-1, infinity or perhaps None, -1) It is hard for me to remember the contexts in which I was wanting to have this equivalency available. Making something up off the top of my head (but probably not very convincing on its own), this way it is easy to do things like: interesting_indexes_list =[ range(1, 11), range(11, 100), range(100, None) ] for rng in interesting_indexes_list: if really_interesting_index in rng: frobnicate_seq_slice(my_seq[rng.start:rng.stop:rang.step])
I suppose my previous message totally ignored that you acknowledged that itertools.count exists. If range were to support infinite ranges, range.__len__ would have to be changed to either raise an error or return float('inf') in these cases. I believe __contains__ would also need to have extra checks. I don't really see the added benefit. On Fri, Jun 19, 2020, 12:23 PM <kempr@edinburghacademy.org.uk> wrote:
On Sat, Jun 20, 2020 at 2:39 AM Steele Farnsworth <swfarnsworth@gmail.com> wrote:
If range were to support infinite ranges, range.__len__ would have to be changed to either raise an error or return float('inf') in these cases.
That would be a problem that would have to be solved, as would related concepts like what slicing with negative indices would do - what's range(0, ...)[:-10] give? This doesn't mean the idea is dead in the water, but anyone who's proposing it will need to come up with answers to these questions.
I believe __contains__ would also need to have extra checks.
That'd be easy enough. The check "x in r" has to check three things: is x >= r.start, is r < x.stop, and is (x - r.start) % r.step == 0. Having an infinite end point would simply remove the need for the middle check (or have it always be true). Be aware that this idea is meaningful ONLY for the 'stop' parameter. An infinite start or step makes no sense. I don't see the value myself, but in theory it would make sense to have both bounded and infinite ranges be able to be processed the same way. ChrisA
My thinking is that if we wanted to represent an unbounded range as a mathematical entity (rather than a tool for iteration), we should let that exist in numpy or another mathematical package so that it can have whatever functionality a mathematician would want it to have without being tied up to the cpython release cycle or backwards compatibility constraints. Steele On Fri, Jun 19, 2020 at 12:47 PM Chris Angelico <rosuav@gmail.com> wrote:
This is not really the best syntax, but I thought this generator expression might be of interest: counter = (d.update(n=d['n']+1) or d['n'] for d in [dict(n=-1)] for _ in iter(int,1)) It counts forever starting at 0. I was playing with only using generator syntax... On Fri, Jun 19, 2020 at 1:32 PM Steele Farnsworth <swfarnsworth@gmail.com> wrote:
How on earth is "count()" not easily available? On Fri, Jun 19, 2020 at 12:23 PM <kempr@edinburghacademy.org.uk> wrote:
-- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.
On Fri, Jun 19, 2020 at 12:25 PM <kempr@edinburghacademy.org.uk> wrote:
If the primary reason is usage in a for loop, why is itertools.count not already sufficient? --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
On Fri, Jun 19, 2020 at 12:29 PM Ricky Teachey <ricky@teachey.org> wrote:
Per my previous response, I don't find the reason given by the OP to be very convincing. However there's another possible reason to want to do this. I have more than once wanted to have infinite ranges that are analogous to infinite slices: slice(None) <=> range(0, infinity or perhaps None) slice(1, None) <=> range(1, infinity or perhaps None) slice(-1, None, -1) <=> range(-1, infinity or perhaps None, -1) It is hard for me to remember the contexts in which I was wanting to have this equivalency available. Making something up off the top of my head (but probably not very convincing on its own), this way it is easy to do things like: interesting_indexes_list =[ range(1, 11), range(11, 100), range(100, None) ] for rng in interesting_indexes_list: if really_interesting_index in rng: frobnicate_seq_slice(my_seq[rng.start:rng.stop:rang.step])
I suppose my previous message totally ignored that you acknowledged that itertools.count exists. If range were to support infinite ranges, range.__len__ would have to be changed to either raise an error or return float('inf') in these cases. I believe __contains__ would also need to have extra checks. I don't really see the added benefit. On Fri, Jun 19, 2020, 12:23 PM <kempr@edinburghacademy.org.uk> wrote:
On Sat, Jun 20, 2020 at 2:39 AM Steele Farnsworth <swfarnsworth@gmail.com> wrote:
If range were to support infinite ranges, range.__len__ would have to be changed to either raise an error or return float('inf') in these cases.
That would be a problem that would have to be solved, as would related concepts like what slicing with negative indices would do - what's range(0, ...)[:-10] give? This doesn't mean the idea is dead in the water, but anyone who's proposing it will need to come up with answers to these questions.
I believe __contains__ would also need to have extra checks.
That'd be easy enough. The check "x in r" has to check three things: is x >= r.start, is r < x.stop, and is (x - r.start) % r.step == 0. Having an infinite end point would simply remove the need for the middle check (or have it always be true). Be aware that this idea is meaningful ONLY for the 'stop' parameter. An infinite start or step makes no sense. I don't see the value myself, but in theory it would make sense to have both bounded and infinite ranges be able to be processed the same way. ChrisA
My thinking is that if we wanted to represent an unbounded range as a mathematical entity (rather than a tool for iteration), we should let that exist in numpy or another mathematical package so that it can have whatever functionality a mathematician would want it to have without being tied up to the cpython release cycle or backwards compatibility constraints. Steele On Fri, Jun 19, 2020 at 12:47 PM Chris Angelico <rosuav@gmail.com> wrote:
This is not really the best syntax, but I thought this generator expression might be of interest: counter = (d.update(n=d['n']+1) or d['n'] for d in [dict(n=-1)] for _ in iter(int,1)) It counts forever starting at 0. I was playing with only using generator syntax... On Fri, Jun 19, 2020 at 1:32 PM Steele Farnsworth <swfarnsworth@gmail.com> wrote:
participants (7)
-
Chris Angelico -
David Mertz -
kempr＠edinburghacademy.org.uk -
Rhodri James -
Ricky Teachey -
Robert DeLanghe -
Steele Farnsworth