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