On 11/14/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > "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.
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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
