> That's the whole point! You don't WANT to know what type it is. You want to > just use it how you want, an if it behaves properly, who cares what type it > is? > > See when you type check you are forcing the user to use those types. What > if they want to derive a subclass from list? Is there really a reason why > you should prevent them from using that subclass with your function? > If there is a valid reason, type checking is fine. But if there isn't, type > checking is just making your code more inflexible. > > Well, I would submit that if were going to do type checking in such a context you'd probably check for a base class, so deriving a subclass wouldn't break entirely. Your point still stands however, we don't even want to require from users to derive from class list. We'd be quite happy to work with any object that "walks like a list" and "quacks like a list", that's the beauty of duck typing...
I guess the question to ask/consider is: How can be establish whether a particular object supports a particular interface/set of behaviours that we require? E.g. how do we most pythonically check whether some object "walks like a list" and "quacks like a list" without tying such code to explicit type checking? Walter
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
