This issue is to add the "object" type to the list of types documented in the language reference's standard type hierarchy and the library reference's list of built-in types:

http://docs.python.org/dev/reference/datamodel.html#the-standard-type-hierarchy
http://docs.python.org/dev/library/stdtypes.html#other-built-in-types

The constructor is documented here:

http://docs.python.org/dev/library/functions.html#object

In the documentation, it might also be worth stating explicitly which of the special methods the object type defines:

http://docs.python.org/dev/reference/datamodel.html#special-method-names

For example, object.__str__ is defined, but object.__bytes__ is not.  By doing this, users will know which special methods user-defined classes will automatically inherit.

good idea

I think there was another issue discussing a separation between object.__str__ and someobject.__bytes__, to make it clear which are existing methods of the object class and which are methods that one may implement in their classes.

Doing this is going to be a bit tricky, since currently links like :meth:`object.__format__` go to the special methods section.  So I think making the distinction between available special methods and ones that object implements will need to be done at the same time as this, and there may be quite a few places in the documentation where reference will need to be changed.

What does not help is that help(ob) omits all the methods inherited from object, *even when ob is object*.  See #20285.

Here is a patch. Perhaps it is what you had in mind. I added quick mentions of the “object” class to The Standard Type Hierarchy and Other Built-in Types. I added documentation of what the object class’s own implementations do where it provides them. I added sentences pointing out that other methods are not provided by the object class, where I thought it may not already be clear. I also added a test case to check that various methods exist or not, to match the documentation.