This paragraph is not as erroneous as misleading because of where it appears: “Custom classes” is the only place in the Data Model documents where __bases__ is addressed at all. Since working with custom classes is the only time you are likely to care about the contents of __bases__ , I think that makes sense.
Surprisingly, it gives a complete description of __bases__ , including details that apply only to non-standard classes such as inline, object . As you pointed out, object.__bases__ empty:
>>> object.__bases__ ()
I think the phrase was supposed to be head-up, that unknown_class.__bases__[0] could raise an IndexError , because even in Python 3, __bases__ could be empty.
__bases__ can also be single, apparently. Why not take care of what I cannot imagine. Maybe "singleton", they meant "1 tuple"? Er, OK ... I don't care.
Update: As wim pointed out, this paragraph was imported along with the entire Python 2 Docs/reference/datamodel.rst from Monday August 15, 2007 and has since remained virtually unchanged. However, the section in which he was located was simply “classes”. This section was renamed “Custom Classes” on Friday August 31, 2007 as part of an effort to remove the “old style” / “new style”.
Adding the word "Custom" does not seem to be an improvement, since the bulk of this section applies to most or perhaps all classes (I don’t know to what extent this applies to classes compiled from another language).
PS: In case someone is tempted to secretly replace the __bases__ attribute after creating the class, Python 3 received a special error message just for you ...
>>> class A: pass ... >>> A.__bases__ (<class 'object'>,) >>> A.__bases__ = () Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can only assign non-empty tuple to A.__bases__, not ()