"George Sakkis" <[EMAIL PROTECTED]> wrote:
>
> On 11/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> > George Sakkis wrote:
> > > On 11/14/06, Fredrik Lundh <[EMAIL PROTECTED]> 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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
