> From: Guido van Rossum [mailto:guido at python.org] > > Such a thing would face zero opposition if it was part of itertools: > > itertools.revrange([start, ] stop[, step]) makes total sense to me... [Paul Moore] > I also like Alex's suggestion of > itertools.irange([start,] stop[, step][,reverse=False]) > > I'd rather this than a revrange - that feels over-specialised, whereas > an irange with a reverse keyword parameter seems natural. Hm, I don't know why it feels that way for you. It would be more verbose and I expect this option will always be a *constant*. (One of my rules-of-thumb for API design is that if you have a Boolean option whose value is expected to be always a constant, you've really defined two methods and API-wise you're better off with two separate methods. Although there are exceptions.) > I'd still support this addition to itertools whether or not the > reversed() builtin was implemented (although with irange, reversed() > loses a lot of its use cases...) Exactly: I am proposing this *because* it takes care of most of the use cases for reversed(), and reversed() doesn't need to be a builtin then. (If we can live with importing i[rev]range() from itertools, we can certainly live with importing the more powerful but less frequently needed reversed() from somewhere.) --Guido van Rossum (home page: http://www.python.org/~guido/)
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