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, seberg
Date 2021-12-14.14:43:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1639492981.73.0.693505890002.issue45383@roundup.psfhosted.org>
In-reply-to
Content
I haven't forgotten this issue, but when I get to it it always leads to a rabbit hole. Sometimes just chasing refleaks, but there are deeper issues as well.

AFAICS, there's no way to call metatype.tp_new for such a class. I guess the safest option is to fail when the metaclass has a custom tp_new -- because that means the metaclass is requesting that it wants to allocate/initialize its types itself.

We can call metatype.tp_init, and probably should. And __init_subclass__ too, I suppose.

But at that point, this is duplicating a lot of existing functionality, and I'm starting to wonder if this wouldn't all be better with calling the metaclass instead.
What's missing?
- basicsize/itemsize could be allowed with __basicsize__/__itemsize__ in the dict.
- flags: we could add mechanisms to set individual flags after the type is created, as needed.
- slots can usually be applied after the class is created; maybe there should be a public function for this.
- members could theoretically be copied to individual descriptors; there doesn't seem much need for keeping tp_members around.

Does that seem like a more reasonable direction to explore?
History
Date User Action Args
2021-12-14 14:43:01petr.viktorinsetrecipients: + petr.viktorin, seberg
2021-12-14 14:43:01petr.viktorinsetmessageid: <1639492981.73.0.693505890002.issue45383@roundup.psfhosted.org>
2021-12-14 14:43:01petr.viktorinlinkissue45383 messages
2021-12-14 14:43:01petr.viktorincreate