Inconsistent behavior of object.__getattribute__ when applied to a type (builtin vs custom class) if attrs are not data descriptors

[alphiy]

Bug report

Bug description:

When applying object.__getattribute__(cls, attr) to a type object, builtin class behave differently from custom class (or instances of class), i.e.

object.__getattribute__(builtin_class, attr)
behaves differently from
object.__getattribute__(custom_class, attr), object.__getattribute__(instance_of_class, attr)

It seems like that object.__getattribute__(builtin_class, attr) doesn't lookup its own dict of builtin class before checking up dict of its metaclass' mro.

# builtin class case
assert '__mul__' in vars(int)
object.__getattribute__(int, "__mul__")
Out: AttributeError: 'type' object has no attribute '__mul__'

# custom class case
class A(int):
    def __mul__(self, *args, **kwargs):
        return super().__mul__(*args, **kwargs)
assert '__mul__' in vars(A)
object.__getattribute__(A, "__mul__") 
Out: <function __main__.A.__mul__(self, *args, **kwargs)> 

After diving into dict checking part of _PyObject_GenericGetAttrWithDict() (v3.14), since metaclass of builtin class is type, which hasn't turn on Py_TPFLAGS_INLINE_VALUES and Py_TPFLAGS_MANAGED_DICT, so the dicts of builtin class or custom class are all treated as computed_dict by dictptr = _PyObject_ComputedDictPointer(obj);. The problem is that the dict of builtin class turns out to be the managed_dict, their tp_dict slot always point to NULL, so it seems like skipping check of their own tp_dict, and finally lead to this kind of inconsistent behavior.

The primitive fix is below, and it works on v3.14

--- a/Objects/object.c
+++ b/Objects/object.c
@@ -1733,6 +1733,21 @@ _PyObject_GenericGetAttrWithDict(PyObject *obj, PyObject *name,
         else if ((tp->tp_flags & Py_TPFLAGS_MANAGED_DICT)) {
             dict = (PyObject *)_PyObject_GetManagedDict(obj);
         }
+        else if (tp->tp_flags & Py_TPFLAGS_TYPE_SUBCLASS) {
+            PyTypeObject * obj_as_type = _Py_CAST(PyTypeObject*, obj);
+
+            /* exactly the same as
+             * dict = lookup_tp_dict(obj_as_type) */
+            if (obj_as_type->tp_flags & _Py_TPFLAGS_STATIC_BUILTIN) {
+                PyInterpreterState *interp = _PyInterpreterState_GET();
+                managed_static_type_state *state = _PyStaticType_GetState(interp, obj_as_type);
+                assert(state != NULL);
+                dict = state->tp_dict;
+            }
+            else {
+                dict = obj_as_type->tp_dict;
+            }
+        }
         else {
             PyObject **dictptr = _PyObject_ComputedDictPointer(obj);
             if (dictptr) {

object.__getattribute__(int, "__mul__")
Out: <slot wrapper '__mul__' of 'int' objects>

Since type objects are only the legitimate self argument of type.__getattribute__, it will raise an error when applied to instances of class. However since everything in Python is object, so everything is legitimate self argument of object.__getattribute__, although it is rare case when applied to type objects in routine usage. And in routine practice, dot operator and getattr() always guarantee instances use __getattribute__ of class and type objects use __getattribute___ of metaclass. So I don't know whether it worth fixing, I just point it out here.

CPython versions tested on:

3.14, 3.12

Operating systems tested on:

Linux, Windows

[ronaldoussoren]

object.__getattribute__ does not necessarily have the same semantics as type.__getattribute__ when the first argument is a type. This is similar to any other method that can be (and in this case is) overridden in subclasses.

Is there a reason why you cannot use the getattr function?

[Locked-chess-official]

I don't think that they should be consistent: PyObject_GenericGetAttr is different from PyType_Type.tp_getattro

[alphiy]

Maybe my previous description is confusing. The inconsistent is not between object.__getattribute__ (or PyObject_GenericGetAttr) and type.__getattribute__ (or PyType_Type.tp_getattro). The inconsistence happens between object.__getattribute__(builtin_class, attr) and object.__getattribute__(custom_class, attr), although in this case, we should use type.__getattribute__ version or getattr. Anyway this doesn't impact in practical use.

[alphiy]

object.__getattribute__ does not necessarily have the same semantics as type.__getattribute__ when the first argument is a type. This is similar to any other method that can be (and in this case is) overridden in subclasses.

Is there a reason why you cannot use the getattr function?

getattr function can't be used in case where need to override the __getattribute__ itself if looking up of same self object, since it will form infinite loop. There are only 3 choices left: object, type and super() version of __getattribute__ which are designed in absolute/relative way respectively.

However your reply sounds convincing to me that type is a subclass of object which overrides the tp_getattro in C-level, so it is not suitable to apply object.__getattribute__ to a type, since it is not designed that way (in this case, only suitable for instances). And this reminds me that it is somehow similar to __setattr__, which will "reject calls that jump over intermediate C-level overrides".

So it is unreasonable to say that there exists inconsistence between object.__getattribute__(builtin_class, attr) and object.__getattribute__(custom_class, attr), since it is not designed to be used that way.

[Locked-chess-official]

getattr function can't be used in case where need to override the __getattribute__ itself if looking up of same self object

Why not using super().__getattribute__ in your metaclass?

[alphiy]

getattr function can't be used in case where need to override the __getattribute__ itself if looking up of same self object

Why not using super().__getattribute__ in your metaclass?

I can, and type.__getattribute__ is also the choice in metaclass. But this is not a point that there is no other alternative choice, the point is that the inconsistence lies in object.__getattribute__ if we assume a type object is the legitimate for its self argument.

So one more question in case there is a communication issue. In developer's perspective view, is logic of PyObject_GenericGetAttr designed to be applied to every objects (including type objects) or just instances of class? If designed to be applied to every objects, if type objects as its self argument is legitimate, then the inconsistent behavior of PyObject_GenericGetAttr is still a problem.

But however as mentioned above considering type as subclass overriding tp_getattro in C level, it sounds reasonable not to apply object.__getattribute__ to a type.