[Python-3000] Builtin iterator type

[Josiah Carlson]

"George Sakkis" <george.sakkis at gmail.com> wrote:
> 
> On 11/14/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> > George Sakkis wrote:
> > > On 11/14/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
> > >
> > >> BJ?rn Lindqvist wrote:
> > >>
> > >>> But why is both the dict and list protocol so fat then? Is it hard to
> > >>> create your own dict or list-derived types in Python?
> > >> don't confuse things like lists and dictionaries with things like
> > >> sequences and mappings.  iterators and iterables belong to the second
> > >> category.
> > >
> > > This doesn't answer my last question: why do we need itertools when we
> > > can live without sequencetools, mappingtools, fileliketools, etc. ?
> >
> > Because the iterator protocol is simple enough to be easily composable - there
> > are a wide variety of things that can be done with an object when all you know
> > about it is that it is some form of iterable. The more assumptions you have to
> > start making about the iterable, the less widely applicable the resulting
> > operation will be.
> >
> > And I think the number one reason we don't see a compelling need for the extra
> > tool libraries you describe is the fact that sequences, mappings and files are
> > themselves all iterables.
> >
> > That said, there are actually a number of modules for working with sequences
> > in the standard library, like bisect and heapq. They just aren't lumped into
> > one place the way itertools and functools are.
> >
> > Having a rich method API vs having a narrow method API and duck-typed support
> > functions is a design trade-off. In the case of sequences and mappings, the
> > trade-off went towards a richer API because the de facto reference
> > implementations were the builtin dict and list classes (which is why DictMixin
> > and ListMixin are so useful when implementing your own containers). In the
> > case of iterables and iterators, the trade-off went towards the narrow API so
> > that the interface could be used in a wide variety of situations (lines in a
> > file, records in a database, characters in a string, bytes from a serial port,
> > frames in a bowling game, active players in a MMORPG, etc, etc, etc).
> 
> Given the overly negative reaction to a base iterator type, I withdraw
> the part of my proposal that suggests this type as the base of all
> iterators. Instead I propose a builtin Iter (or even better iter, if
> there is no objection to change iter's current behavior) as an OO
> replacement of the (functional) itertools API. In other words, instead
> of:

-1.  There is nothing wrong with a functional approach.  If you dislike
the verbosity of the names of the operations, and/or the arguments they
take, you are free to rename them:
    from itertools import chain as CH
... or write wrappers:
    def IS(it, start):
        return islice(it, start, None)

You can even have your itertools automatically inserted into
__builtins__ on startup with a small manipulation of site.py .

Heck, if _you_ want them, _you_ are free to have your Iter object
inserted into the __builtins__ namespace by site.py .  But due to the
overwhelming -1s from _everyone_, _including Guido_, your odds of
getting anything like Iter into mainline Python in the next 18 months 
(when Python 2.6 is expected to be released), is very low.

 - Josiah