Guido van Rossum <guido at python.org> writes:
>> Candidate itertools are expected to accept general iterables as inputs
>> and to work well with each other. This function accepts only sequences
>> as inputs and cannot handle outputs from other itertools. IOW, it
>> doesn't belong in the toolset.
>
> Ah, you misunderstood. I was only arguing for irange(...,
> reverse=True) or irevrange(...); since irange() is already in
> itertools, there can clearly be no objection to adding the reverse
> option somehow.
Actually, irange() is not in itertools at the moment. Raymond could
argue that irange() isn't a suitable candidate for itertools, but given
the existence of count() and repeat(), I suspect that isn't a
particularly convincing argument.
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.
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.
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.
> 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].
Paul.
--
This signature intentionally left blank
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