[Python-3000] Builtin iterator type
ncoghlan at gmail.com
Tue Nov 14 16:30:15 CET 2006
George Sakkis wrote:
> Understood. Any _technical_ reasons then why shouldn't all iterators
> inherit from it, or "duck typing is The Right Way" should be taken as
> an axiom ? Why do we somehow _need_ itertools when we don't need
> sequencetools, mappingtools, etc ? What's so special about the
> iterator protocol ?
I have sympathy for the idea of syntactic sugar for working with iterators, I
really do (just read the thread I started about iterator slicing early last
However, since that time we've moved on to the idea of returning richer view
objects rather than bare iterators for some of the methods being changed in
Py3k to return something other than a list (such as dict.keys() and friends).
The underlying realisation behind that change is that an iterable is free to
implement whichever aspects of the sequence and mapping interfaces it wants
to, depending on what makes sense for the particular iterator.
By taking this route the basic iterator protocol is kept simple with minimal
assumptions about the underlying data storage (which is exactly what leads to
the protocol's wide applicability), while the richer mapping and sequence
interfaces are supported as appropriate in order to make the objects easier to
The difficult with pulling views out into a generic mixin class such as the
one you propose is that they are typically strongly coupled to their
associated concrete container class. Arbitrary iterators don't make strong
enough guarantees to allow that to work without suprises.
For example, it would be somewhat surprising if (a, b, c), (x, y, z) = it[:3],
it[:3] puts different results into a & x, but that is exactly what happens if
'it' is a sliceable iterator like the one you suggest. This didn't bother me
last year, but I've since grown to dislike it (primarily due to the
realisation mentioned above that returning view objects where appropriate is
likely to be a better answer, even if it lacks "one idiom to rule them all"
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-3000