Message410962
I'm looking at the _PyType_GetModuleByDef optimization in https://github.com/python/cpython/pull/25504/files -- previously I assumed it's OK since it passed review.
But it doesn't look correct:
- in the `_PyType_HasFeature` assert, we should be looking at `super` rather than `type`
- it's definitely possible that a hear type has a static type in the MRO -- `object`, at least. The `(PyHeapTypeObject*)super` cast is invalid in the case when the module is not found. And it's *also* incorrect in some cases of diamond inheritance, when a static type comes before the type we're looking for in `bases`.
It also adds a precondition that's not feasible public API, which this was meant to become: it should be callable with any type object. That's possible to do by keeping faster internal API and adding a public version with checks, but the diamond inheritance problem remains. Py_TPFLAGS_HEAPTYPE needs to be checked at runtime (except for the first iteration, if we're sure we're handling a static type).
Does that analysis sound right? |
|
Date |
User |
Action |
Args |
2022-01-19 15:46:37 | petr.viktorin | set | recipients:
+ petr.viktorin, vstinner |
2022-01-19 15:46:37 | petr.viktorin | set | messageid: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org> |
2022-01-19 15:46:37 | petr.viktorin | link | issue46433 messages |
2022-01-19 15:46:37 | petr.viktorin | create | |
|