Message408532
| 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:01 | petr.viktorin | set | recipients:
+ petr.viktorin, seberg |
| 2021年12月14日 14:43:01 | petr.viktorin | set | messageid: <1639492981.73.0.693505890002.issue45383@roundup.psfhosted.org> |
| 2021年12月14日 14:43:01 | petr.viktorin | link | issue45383 messages |
| 2021年12月14日 14:43:01 | petr.viktorin | create |
|