It seems that the xrange object in the current CVS can't make up its mind
whether it's an iterator or an iterable:
>>> iterables = ["", (), [], {}, file('/dev/null'), xrange(10)]
>>> iterators = [iter(x) for x in iterables]
>>> for x in iterables + iterators:
... print hasattr(x, 'next'), x is iter(x), type(x)
...
False False <type 'str'>
False False <type 'tuple'>
False False <type 'list'>
False False <type 'dict'>
False False <type 'file'>
True False <type 'xrange'>
True True <type 'iterator'>
True True <type 'iterator'>
True True <type 'listiterator'>
True True <type 'dictionary-iterator'>
True True <type 'xreadlines.xreadlines'>
True False <type 'xrange'>
Generally, iterables don't have a next() method and return a new object
each time they are iter()ed. Iterators do have a next() method and return
themselves on iter(). xrange is a strange hybrid.
In Python 2.2.0/1 xrange behaved just like the other iterables:
>>> iterables = ["", (), [], {}, file('/dev/null'), xrange(10)]
>>> iterators = [iter(x) for x in iterables]
>>> for x in iterables + iterators:
... print hasattr(x, 'next'), x is iter(x), type(x)
...
0 0 <type 'str'>
0 0 <type 'tuple'>
0 0 <type 'list'>
0 0 <type 'dict'>
0 0 <type 'file'>
0 0 <type 'xrange'>
1 1 <type 'iterator'>
1 1 <type 'iterator'>
1 1 <type 'iterator'>
1 1 <type 'dictionary-iterator'>
1 1 <type 'xreadlines.xreadlines'>
1 1 <type 'iterator'>
What's the rationale behind this change?
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