New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tp_(get|set)attro? inheritance bug #40418
Comments
Documentation says, regarding tp_getattr: Implementation disagrees, at least in cvs head, but In function type_new (typeobject.c) line 1927:
/* Special case some slots */
if (type->tp_dictoffset != 0 || nslots > 0) {
if (base->tp_getattr == NULL &&
base->tp_getattro == NULL)
type->tp_getattro =
PyObject_GenericGetAttr;
if (base->tp_setattr == NULL &&
base->tp_setattro == NULL)
type->tp_setattro =
PyObject_GenericSetAttr;
}
...later in the same function...
/* Initialize the rest */
if (PyType_Ready(type) < 0) {
Py_DECREF(type);
return NULL;
}
Inside PyType_Ready(), line 3208:
for (i = 1; i < n; i++) {
PyObject *b = PyTuple_GET_ITEM(bases, i);
if (PyType_Check(b))
inherit_slots(type,
(PyTypeObject *)b);
} Inside inherit_slots, line (3056):
that type_new first sets tp_getattro = GenericGetAttr,
base has tp_getattr, that code path won't be execute.
code block to after the PyType_Ready() call. |
Logged In: YES Guido, is this a bug? |
Logged In: YES Without wanting to think about this terribly hard, wouldn't a |
Logged In: YES No time to think about this more, but yes, a type should |
Logged In: YES PyGTK implements only tp_getattr, none of tp_getattro, We already have a workaround in pygtk, but it was my civic |
Not a bug, then? Will close unless someone argues against it. |
If this problem does not apply to Python 3.x, by all means go ahead and |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: