In 3.3. Special method names, 'object' is used as a pseudo class name to prefix all the special method entries. This conflicts with the usual two Python meanings.

1. 'object' is the name of a specific class. So the entry for object.__getattribute__(self, name) says to avoid circularity by calling
object.__getattribute__(self, name), which looks circular and requires a bit a mental work by the reader to properly understand. Ditto for
object.__setattr__(self, name, value) calling
object.__setattr__(self, name, value)

2. Non-specifically, 'object' is usually understood to mean any Python object, not just a class. But the signatures as written require that 'object' specifically be a class and 'object' does not convey that.

So for both reasons, I propose that the pseudoname 'object' be replaces with 'class' or 'someclass'

I also think that in "In order to avoid infinite recursion in this method, its implementation should always call the base class method with the same name to access any attributes it needs, for example, object.__getattribute__(self, name).", 'the base class' should be 'a base class' or 'a superclass' since there might be more than one base/super class. Ditto for __setattr__.

I filed this because I just reread the __getattr(ibute)__ entries to respond to #8722 and found myself again stumbling over the 'object' confusion.

Good catch!

Names listed under language reference section 3.3.1 actually all exist on object, e.g. object.__new__¹. It is section 3.3.2 that lists names that *can* be defined but don’t have a default implementation on object, so +1 on using “someclass” here to be clear. Oh, and let’s change “class” to “someclass” too in the examples under 3.3.4, to use valid syntax and consistent naming.

I think we should not change “the base class”, since even with multiple bases a class still has one most immediate parent, found in cls.__base__ (a.k.a. cls.__bases__[0]).

¹ with the exception of __bool__ and the lack of __reduce{_ex,}__ and __subclasshook__; I’ll open a bug about those.