Correct type for a simple "bag of attributes" namespace object

[Steven D'Aprano]

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