On Tuesday 04 November 2003 12:26 am, Guido van Rossum wrote: > > > BTW, Alex said he was +1 on the idea, but only +0 on it being a > > > builtin. > > > > Uh, did I? OK maybe I did. But what about "revrange" (which I'd LOVE > > to incarnate as an iterator-returning irange with an optional reverse= > > argument) -- was that knocked out of contention? I claimed that just > > revrange would be too specialized BUT irange would be JUST RIGHT... > > This surprised me a bit too. The majority of Raymond's examples in > the PEP (when I last saw it a week ago) were reverse numeric ranges, > usually of the form revrange(n) -- which we currently have to spell as > range(n-1, -1, -1) (I think :-) and which the new proposal would turn > into reversed(range(n)). According to Raymond, a built-in that would > do just that only drew (a small number of) negative responses in the > newsgroup. > > Such a thing would face zero opposition if it was part of itertools: > itertools.revrange([start, ] stop[, step]) makes total sense to me... And what about irange with an optional reverse= argument? I did have (and write about on c.l.py) a case where I currently code: if godown: iseq = xrange(len(sq)-1, start-1, -1) else: iseq = xrange(start, len(sq), 1) for index in iseq: ... and would be just delighted to be able to code, instead, for index in irange(start, len(sq), reverse=godown): ... Even when the need to reverse can more easily be hardwired in the source (a more common case), would for index in irange(start, stop, reverse=True): be really so much worse than for index in revrange(start, stop): ...? Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4