[Python-3000] Builtin iterator type

Nick Coghlan 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 
year [1]).

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 
work with.

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" 
status).

Regards,
Nick.

[1]
http://mail.python.org/pipermail/python-dev/2005-January/051257.html

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org


More information about the Python-3000 mailing list