[Python-3000] Builtin iterator type

[George Sakkis]

On 11/14/06, Nick Coghlan <ncoghlan at gmail.com> wrote:

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

Nick,

thank you for the most useful and insightful reply so far. Maybe you
are a year ahead of me because the example you showed doesn't bother
me either, the same way I'm not bothered by, say, infinite iterators
and the risk they introduce when someone writes list(iterator). I'm
also not bothered at all with numpy arrays returning views instead of
copies. Is it really part of the informal sequence protocol that
slicing must return a copy ? That would be new to me.

I haven't read the thread you mention about rich views, I probably
should do that, but from the sound of it, I think I'll like it.

Regards,
George