[Python-3000] Builtin iterator type

[Mike Orr]

On 11/14/06, George Sakkis <george.sakkis at gmail.com> wrote:
> 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?"

I came to Python from Java and originally thought this. The answer I
received was as I described: methods are for a certain class
hierarchy, while functions are for an unknown number of potential
types that exhibit a certain behavior.  So you can call len() on both
lists and strings.  Here Java has an inconsistency: array.length vs
String.length().  This in itself illustrates my point.  Different
types necessarily have different implementations.  But if the left
hand isn't watching closely what the right hand is doing, you end up
with cross-class inconsistencies and incompatibilities.  len() here is
a unifier: it says "thou shalt do this, .__len__ method, or users will
be pissed that len() doesn't work on your type".

Python made mistakes along the way in terms of method/function
distribution, but these are gradually being corrected.  The most
notorious were string functions.  Who wants to call string.find(s,
sub) or string.split(s)?  But these have long been replaced by
methods.  My work on a Path object is along the same lines.

The #1 complaint I hear about Python from non-users is indentation,
not too many functions.  People generally praise Python's clean method
interface in its file objects, list/str/dict objects, and its stdlib
namespaces.  These aren't perfect but they're better than many
languages.  I was very pleased that typecasting in Python is as
straightforward as int() and str(), and calling a function
instantiates it.  Much more straightforward than " Foo x = new Foo()".

> I am totally
> amazed that I have itertools in higher esteem than many/most core
> Python developers.

I esteem itertools, I just don't have much need for those operations.
I'm glad it's there because it has better (less memory intensive)
implementations than I'd likely make on my own, and it shows ways to
use iterators that I'd never considered.

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

That's a good point, the overhead of adding a method is not really
worse than adding a function.  I wouldn't object to an iter() function
that returns a SuperIterator, able to slice tall iterables in a single
bound, er, cut.  But I'm not a core developer so I don't understand
all the ramifications it might have. That's a point worth pressing
though: what's the harm in having iter() return an object that's
"sma-a-a-rter than your average bear!", er, than your average
iterator.

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

Actually, it's easier to add a method or package function than to add
a builtin.  Every additional builtin makes it harder to keep all the
builtins in your head, and runs the risk of colliding with a variable
in existing code.  And as Cheetah discovered, it's not safe to
autogenerate Python code based on what the builtins are, because a
future version of Python will add ones you can't predict.  enumerate()
and zip() were added because they solve extremely widespread problems.
 I can't say I like sorted() and reversed(), but they're there because
somebody thought they'd be very widely used.

-- 
Mike Orr <sluggoster at gmail.com>