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 _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
