This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author petr.viktorin
Recipients petr.viktorin, vstinner
Date 2022-01-19.15:46:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
In-reply-to
Content
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?
History
Date User Action Args
2022-01-19 15:46:37petr.viktorinsetrecipients: + petr.viktorin, vstinner
2022-01-19 15:46:37petr.viktorinsetmessageid: <1642607197.61.0.0970144809853.issue46433@roundup.psfhosted.org>
2022-01-19 15:46:37petr.viktorinlinkissue46433 messages
2022-01-19 15:46:37petr.viktorincreate