The short answer was already given, but for anyone who wants the full one: Many many years ago, Python had two separate type hierarchies, similar to what you s

The short answer was already given, but for anyone who wants the full one: Many many years ago, Python had two separate type hierarchies, similar to what you see in Java. There was one hierarchy for Python's built-in types, and another hierarchy for classes. Among other things, this meant you couldn't subclass the built-in types (this is why, for example, there used to be a 'UserDict' class you could use to write things that mostly acted like subclasses of dict). Python 2.2 began the process of unifying the two hierarchies. This was accomplished, ironically, by creating a split in Python's classes. To opt in to the new approach, you wrote a class which had 'object' among its ancestors, either as its direct parent or as a grandparent, great-grandparent, etc. These were called "new-style classes", to distinguish from "old-style" (pre-2.2 behavior) classes. class Foo: pass # This is an old-style class class Bar(object): pass # This is a new-style class "New-style classes" provided the rich data model, including special protocol methods, Python programmers are now used to, along with the ability to subclass built-in types. In Python 3, the distinction was finally removed (because it was backwards-incompatible, it had to wait for Python 3), and now all classes are "new-style", regardless of whether they explicitly have 'object' somewhere in their ancestors. Any codebase that's already Python 3+ only does not need to subclass 'object' to get the expected behavior. Any codebase that still supports Python 2 should continue to subclass 'object' to get new-style classes, until such time as it can migrate to Python 3+ only.