[Python-3000] Builtin iterator type

[Greg Ewing]

George Sakkis wrote:

> I think I do, though I can't tell the same about the reasons of your
> objections to it.

Perhaps I can fill in some of the things that Guido
is not explicitly saying.

You've shown that it *can* be done, but you haven't
provided a compelling reason why it *should* be done.

The main benefit seems to be that itertools operations
could then be done using method calls instead of
function calls. But that's not automatically better
than what we have now. Python does not follow the
"everything must be a method of something" ideology
found in some other languages such as Java and Ruby.

The itertools functions have generic implementations
that work with any iterator. They don't need access
to the iterator's internals, or need to be dynamically
dispatched for any reason, so there is no obvious
benefit to making them methods instead of stand-alone
functions.

The one technical benefit appears to be the ability
to use operators instead of named functions. But
considering how infrequently itertools operations
are used, having to spell them out doesn't seem
like a great hardship, so this argument is weak.
All other things being equal, it might hold sway,
but other things are not equal.

You claim that duck typing would not be inhibited.
While technically this is true, in practice it would
mean that any iterator that didn't inherit from this
base class would be a second-class citizen, unable
to be used by code that expected it to have all the
"standard" itertools methods.

Finally, consider that there are infinitely many
possible functions of the kind that are found in
the itertools module. As stand-alone functions,
they all have equal status -- new ones can be added
and used in the same way by any code on any
iterator. Some good arguments would have to be
put forward as to why some particular ones should
be picked out and elevated to the status of methods.

--
Greg