Andrew Koenig wrote: > Some people in this discussion have suggested that the Pythonic > way to answer this question is to try to use it as an iterator and see if it > raises an exception.
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?-) > I think we should not use inheritance as the > mechanism for specifying that a particular class has a particular ability. > I don't know what the mechanism should be, but it shouldn't be inheritance. 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. There have been various proposals before for ways of registering interfaces outside of the inheritance hierarchy. It wouldn't be hard to come up with something if it were thought desirable. I'm still not convinced that it solves a problem that really needs solving, however. -- Greg _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
