On Tue, Jun 04, 2002 at 04:01:24PM -0500, Jeff Epler wrote:
> On Tue, Jun 04, 2002 at 04:08:08PM -0400, Oren Tirosh wrote:
> > It seems that the xrange object in the current CVS can't make up its mind
> > whether it's an iterator or an iterable:
>
> In 2.2, xrange had no "next" method, so it got wrapped by a generic
> iterator object. It was desirable for performance to have xrange also
> act as an iterator.
I understand the performance issue. But it is possible to improve the
performance of iterating over xranges without creating this unholy chimera.
>>> type([]), type(iter([]))
(<type 'list'>, <type 'listiterator'>)
... lists have a listiterator
>>> type({}), type(iter({}))
(<type 'dict'>, <type 'dictionary-iterator'>)
... dictionaries have a dictionary-iterator
>>> type(xrange(10)), type(iter(xrange(10)))
(<type 'xrange'>, <type 'xrange'>)
... why shouldn't an xrange have an xrangeiterator?
It's the only way to make xrange behave consistently with other iterables.
> However, the following code would give different results if 'iter(x)
> is x' for xrange objects:
> x = xrange(5)
> for a in x:
> for b in x:
> print a,b
xrange currently is currently stuck halfway between an iterable and an
iterator. If it was made 100% iterator you would be right, it would
break this code. What I'm saying is that it should be 100% iterable.
I know it works just fine the way it is. But I see a lot of confusion on
the python list around the semantics of iterators and this behavior might
make it just a little bit worse.
Oren
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