Author haberman2
Recipients Alexander.Belopolsky, Arfrever, Christian.Tismer, Robin.Schreiber, amaury.forgeotdarc, belopolsky, haberman2, jcea, jhaberman, lekma, loewis, mattip, petr.viktorin, pitrou, seberg, steve.dower
Date 2021-09-27.15:48:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1632757734.47.0.602166565039.issue15870@roundup.psfhosted.org>
In-reply-to
Content
> I consider Py_tp_bases to be a mistake: it's an extra way of doing things that doesn't add any extra functionality

I think it does add one extra bit of functionality: Py_tp_bases allows the bases to be retrieved with PyType_GetSlot().

This isn't quite as applicable to the metaclass, since that can easily be retrieved with Py_TYPE(type).

> but is sometimes not correct (and it might not be obvious when it's not correct).

Yes I guess that most all slots are ok to share across sub-interpreters.  I can see the argument for aiming to keep slots sub-interpreter-agnostic.

As a tangential point, I think that the DLL case on Windows may be a case where Windows is not compliant with the C standard: https://mail.python.org/archives/list/python-dev@python.org/thread/2WUFTVQA7SLEDEDYSRJ75XFIR3EUTKKO/

Practically speaking this doesn't change anything (extensions that want to be compatible with Windows DLLs will still want to avoid this kind of initialization) but I think the docs may be incorrect on this point when they describe Windows as "strictly standard conforming in this particular behavior."
History
Date User Action Args
2021-09-27 15:48:54haberman2setrecipients: + haberman2, loewis, jcea, amaury.forgeotdarc, belopolsky, pitrou, Arfrever, petr.viktorin, lekma, Alexander.Belopolsky, mattip, Robin.Schreiber, steve.dower, seberg, Christian.Tismer, jhaberman
2021-09-27 15:48:54haberman2setmessageid: <1632757734.47.0.602166565039.issue15870@roundup.psfhosted.org>
2021-09-27 15:48:54haberman2linkissue15870 messages
2021-09-27 15:48:54haberman2create