Christian Tismer <tis...@stackless.com> added the comment:
Petr, Fine! PySide's problems are solved for now, no worries. But as mentioned, there is more. Problem 1) ---------- There is another thing that gives problems: When creating types which have fields "behind" the normal type fields, PySide had explicit structs that contained PyHeaptypeObject explicitly, plus the extra fields. We changed that into a normal PyType declaration (opaque) and a pointer expression that dynamically computed the offset. For that, we needed sizeof(PyType_Type). Ok, that could be solved by Python code, but this "trick" is not so obvious and should be documented, or a variable should be provided that gives the heap type size, dynamically. Problem 2) ---------- Harder is this: For some operations, we needed access to fields of normal types, for instance the tp_new field of PyType_Type. That is not possible, although it would be easy: PyType_GetSlot forbids access to normal types, rigorously. But concerning the "normal" type fields, those which are not indirections, it would cost nothing to allow this for normal types. This uses a property of types which has not explicitly been used: * All types have the same basic structure * That means, we can allow access to all "tp_" fields with simply changing a check in PyType_GetSlot. I'm not sure if that information should be made official. May be it should be hidden and PyType_GetSlot should be made more complicated. But the proposed change comes at no cost. And the prefixes like "nb_" or "sq_" are still visible, so I don't think there was an intent to make type structures completely opaque? For PySide, it was crucial to use that information to compute the offset of certain fields of normal types, which is a bit of a Pep 384 breach. We wrote code that verifies that these assumptions are all valid, but I would be happy to remove that and revert to only using PyType_GetSlot. Please let me know if I can help with something! Cheers - Chris ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue26979> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
