Josh Haberman <haber...@google.com> added the comment:
> 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-...@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." ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue15870> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
