[Python-3000] Builtin iterator type

[Andrew Koenig]

> That's not what I would say. I would say that you
> should design your code so that you don't *need*
> to find out whether it's an iterator or not. Instead,
> you just require an iterator, always, and trust that
> the calling code will give you one. If it doesn't,
> your unit tests will catch that. (You *do* have
> unit tests, don't you?-)

That's a nice general sentiment, but not always feasible -- especially if
you're writing library code.  Remember, I'm thinking about abilities in
general, not just whether a type is an iterator.  For example, testing
whether something is an iterator by trying to call its next() method is
destructive if it succeeds.  So consider the following:

	def concat(x, y):
		for a in x: yield a
		for a in y: yield a

Simple as this function may be, it has a drawback: If x is an iterator and y
is not a valid sequence, the function consumes x before failing.  If it were
possible to determine nondestructively whether y is a sequence, the function
would not have this drawback.  The drawback in this particular example may
be trivial; but similar drawbacks can be serious in other contexts,
especially where networking is involved.

> Your ability-signallers seem to be something akin to
> the Haskell notion of typeclasses. A typeclass is not
> itself a type, but represents a set of characteristics
> that a type can have

To the extent that I'm familiar with Haskell, I think you're right.