[Python-3000] Builtin iterator type

[George Sakkis]

On 11/14/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> 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.

Indeed, another high quality reply. Thanks for sharing.

> 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.

I won't open another can of worms here, but I'll just say that as much
as I hate Java's stubborn insistence on OO purity, I am equally
disturbed by Python's arbitrary-looking choices on whether some
callable ends up a function or a method. When I talk about or
introduce Python to outsiders, one of the toughest questions is often
something along the lines of "why len() is a function and not a
method?"

> 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.

Did you look at my implementation ? The only attribute is a reference
to the underlying iterator. No access to its internal is needed.

> 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.

This seems to be the most central, and at the same time most
unexpected for me, point of resistance. Given the prominence of
iterators, generators, generator comprehensions and generic iterables
in Python, I've been considering itertools the module that makes all
these "talk" to each other seamlessly and transparently. I am totally
amazed that I have itertools in higher esteem than many/most core
Python developers.

> 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.

The promotion from second class to first would require 6 extra
characters: Iter(x) (or iter(x) if it's ok to augment the existing
iter()). Just spelling "itertools" takes more than that, let alone
importing a function or two. The runtime cost would be negligible too
since Iter is a thinnest wrapper around x (or it could be x itself if
it was already "first-class").

> 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.

I'm not sure I understand your point here. If something was deemed
useful enough to make it to itertools, it would be a candidate for
being a method to a base Iter type. I don't have any strong feelings
on the exact set of methods that I want to see included apart from the
most basic ones (chain as +, islice as [], izip as zip and enumerate -
yes, I count enumerate as an iter tool). Besides, types, like modules,
are not carved in stone. It's not as if no builtin type or function in
Python has ever grown (in a backwards compatible way) more methods,
extra named arguments, etc. I guess the good arguments to be put
forward for every candidate method would be similar to the ones that
elevated enumerate() and reversed() to builtin status.

George