> Arguing that irange() is too similar to range() and xrange() is
> closer, but I'd say that irange is the *right* way to do it. [x]range
> should be relegated to backward-compatibility tools, much like the
> file xreadlines() method and the xreadlines module.
Hm. There's a usage pattern that seems easy with [x]range() but not
so easy with irange():
R = xrange(...)
for x in R: ...
for y in R: ...
IMO, being able to say "for x in R" rather than having to remember the
arguments to irange() and having to say "for x in irange(a, b, c)" is
a big and useful advantage.
IOW [x]range() returns a *sequence* which is more powerful than an
iterator, because it can be iterated more than once.
Now, the same could be accomplished with copyable iterators, but it
is still more work:
I = irange(...)
R1, R1 = tee(I)
for x in R1: ...
for x in R2: ...
> Raymond - are you dead set against an irange() function in itertools?
> Assume for now that it's a simple version without a reverse argument.
>
> > But since (a) at least 60% of the examples are satisfied with
> > something like irevrange(), and (b) having irevrange() in itertool
> > is acceptable, my (c) conclusion is that reversed() doesn't need to
> > be a builtin either. I didn't say it had to go into itertools!
>
> Raymond seems very protective of the concept of reversed() as a
> builtin. I'm not saying that's wrong, but I *personally* haven't seen
> enough evidence yet to be convinced either way. The i{rev}range()
> issues seem to be getting caught up in this.
Right.
> My view:
>
> 1. I think a "plain" irange() would be useful to add into itertools.
> In the (very) long term, it could replace [x]range, but that's less
> of an issue to me.
> 2. A way of getting a reversed {i,x}range() has some clear use cases.
> This seems useful to add (although here, I'm going on evidence of
> others' code - in my code I tend to loop over containers much more
> often than over ranges of numbers).
> 3. A general reversed() function seems theoretically useful, but the
> concrete use cases seem fairly thin on the ground. I'm broadly in
> favour, because I (possibly like Raymond) have a bias for clean,
> general solutions. But I can see that "practicality beats purity"
> may hold here.
>
> My proposals:
>
> 1. Add a plain irange() to itertools.
> 2. IF the general reversed() is deemed too theoretical, add EITHER a
> reverse argument to irange, or an irevrange to itertools. Both feel
> to me a little iffy, but that's my generality bias again.
> 3. IF the general reversed() is accepted (builtin or not) leave the
> irange function in its simple form.
Hm. reversed(irange(...)) can't work, so you'd have to have both.
> > Sorry, I have to push back on that. We still need to contain the
> > growth of the language, and that includes the set of builtins and (to
> > a lesser extent) the standard library. You have to show that this is
> > truly important enough to add to the builtins. Maybe you can propose
> > to take away an existing builtin to make room *first*.
>
> xrange (in favour of itertools.irange())? :-)
>
> [Personally, I'm still not 100% sure I see Raymond's strong reluctance
> to have reversed() in itertools, but as both are his babies, and he
> clearly has a very definite vision for both, I don't feel that I want
> to argue this one with him].
That part I understand. reversed() is a function of a sequence
(something with __len__ and __getitem__ methods), not of an iterator,
and as such it doesn't belong in itertools.
--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