Terry Reedy wrote: > The object class is used to implement duck typing. It is the delegation > of operations to class instance methods that makes extensible duck > typing possible.
That cannot possibly be true, because Python had duck typing before it had object. object and new-style classes were introduced in Python 2.2, which means that there were a good half-dozen versions of Python, including the very popular 1.5, where people couldn't use object. (Also, I'm not sure what you mean by "class instance methods" -- methods can be class methods, or they can be instance methods, but not both at the same time.) > 'a + b' is equivalent to type(a).__add__(a, b) It's actually more complicated than that, because type(b).__radd__ also gets considered, but either way, I don't think that the *implementation* of + is relevant here. Duck-typing isn't really a mechanism, in the sense that static/dynamic or strong/weak typing are mechanisms: - static typing means that the compiler can tell at compile-time what type a variable will have, and prohibit code which may violate that constraint; - dynamic typing means that types are associated with values, not with variables; - strong typing means that the compiler will do nothing (or very little) to automatically convert values from one type to another; - weak typing means that the compiler will do a lot to automatically convert values from one type to another, including possibly some conversions which are considered by many to be unsafe or silly. Duck-typing is more of a programming philosophy than a mechanism, at least in Python: - you shouldn't care whether a value has a specific type or not, but whether it exposes the interface you care about. Some languages (like Java) try to formalise this, providing a mechanism by which you can implement a particular interface in a way known to the compiler: https://en.wikipedia.org/wiki/Interface_%28Java%29 Python's ABCs (abstract base classes, introduced in version 2.6) are similar. In both cases, they use the type system (in Java's case, at compile-time, in Python's case, at run-time) to check for an interface up-front, i.e. a form of "Look Before You Leap". In Python, duck-typing can also be more ad hoc and informal: if you want to know whether an object provides a certain interface, you typically just try it and see if it breaks, hoping that it will raise an exception sooner rather than later (i.e. "Easier to Ask for Forgiveness than Permission"). That's why I call it more of a philosophy than a mechanism. Duck-typing, of course, is not infallible. Suppose you're expecting an Artist, and call the artist.draw() method, but somebody gives you a Gunfighter instead. There's also the problem of what to do when an object provides only *part* of an interface: sometimes, by the time you have to ask forgiveness, you've already made irreversible changes to something (a file, a database, or launched the missiles). -- Steven -- https://mail.python.org/mailman/listinfo/python-list
