[Python-3000] Builtin iterator type

[George Sakkis]

On 11/14/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> "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.

This is the python-3000 list; I don't aim at Python 2.x. Given that I
propose to *replace* itertools, not add an extra builtin (having them
both would be redundant and violates the one obvious way to do it
principle), it wouldn't be backwards compatible. As for the -1s, so
far most of them seem to oppose the inheritance idea as a worse option
than duck typing; let's see if removing this part changes anything.

As for your other arguments about renaming the itertools functions to
smaller names, let me remind you that in python syntax sugar *does*
matter. If I am not mistaken, the list comprehension syntax will not
be removed in python-3K, although it is completely redundant with
generator comprehensions. Heck, writing list(gencomp) is only 4
characters longer than [gencomp]. My suggested proposal does much
better, both in saving keystrokes and readability.

George