[Edu-sig] Python types, iterators in particular

[kirby urner]

Speaking of types, I'm not seeing a generic 'iterator type' in the types module.
Then we have all these special types for iterable objects:

>>> type(xrange(10))
<type 'xrange'>
>>> type((i for i in range(10)))
<type 'generator'>
>>> type(enumerate((1,2,3,4)))
<type 'enumerate'>
>>> type(iter([1,2,3,4,5]))
<type 'listiterator'>
>>> type(iter((1,2,3)))
<type 'tupleiterator'>

Noting:
"""
(In retrospect, it might have been better to go for __next__()
and have a new built-in, next(it), which calls it.__next__().
But alas, it's too late; this has been deployed in Python 2.2
since December 2001.)
"""
[ http://www.python.org/dev/peps/pep-0234/ ]

Is this part of what's fixed in Python 3.0 then?  Plus there'll be some
type integration under the concept if 'iterator type'?  I've heard Guido's
latest 3.0 talk twice now, and that's the impression I'm left with.

Background to this question (writing about Python 3.0 on another list):

"""
The details are interesting too. What's been emerging in computer
science is this notion of "lazy evaluation" akin to "just in time"
in many dimensions (another important meme). In Python, this was
foretold by xrange, a prophetic __builtin__ in retrospect. xrange
will be simply range in Python 3.x.

What did xrange foretell? Lazy evaluation. Instead of pre-allocating
gobs of memory, just save the algorithm for getting the *next* in
the sequence, only deliver when specifically asked.

Constructs such as 'for p in primes:' don't seem so strange any
more, because 'primes' isn't an infinite chunk of memory, so much
as a factory for a sequence of values, to be delivered conveyor
belt style, but only when a .next() button is pressed.

All that __next__ button pushing takes time, and in the mean time,
Python is off doing other things.

However, this notion of an "iterable" (source of next values) wasn't
so clear in the early days of Python. xrange foretold it, but now
we have explicit generators and generator expressions.

We've since elevated 'iterable' to a known type (a 'duck type' as
we say) and return it more consistently as such, and not just by
xrange (soon to be just range, taking the place of the old memory
pre-allocating version).

These innovations were just not conceived of in the earliest Pythons.
So rather than focusing on Guido's "mistakes" (aka "regrets"), we
have the option to just talk about advances, and Python's amazing
ability to adopt them, cleanly and intelligently (a tribute to its
namesake).
"""

Kirby