
On Wed, Feb 23, 2022 at 9:16 AM Petr Viktorin <encukou@gmail.com> wrote:
But tp_dict is also public C-API. How will that be handled? Perhaps naively, I thought static types' dicts could be treated as (deeply) immutable, and shared?
They are immutable from Python code but not from C (due to tp_dict). Basically, we will document that tp_dict should not be used directly (in the public API) and refer users to a public getter function. I'll note this in the PEP.
What worries me is that existing users of the API haven't read the new documentation. What will happen if users do use it? Or worse, add things to it?
We will probably set it to NULL, so the user code would fail or crash. I suppose we could set it to a dummy object that emits helpful errors. However, I don't think that is worth it. We're talking about where users are directly accessing tp_dict of the builtin static types, not their own. That is already something they should definitely not be doing.
(Hm, the current docs are already rather confusing -- 3.2 added a note that "It is not safe to ... modify tp_dict with the dictionary C-API.", but above that it says "extra attributes for the type may be added to this dictionary [in some cases]")
Yeah, the docs will have to be clarified.
Having thought about it some more, I don't think this PEP should be strictly bound to per-interpreter GIL. That is certainly my personal motivation. However, we have a small set of users that would benefit significantly, the change is relatively small and simple, and the risk of breaking users is also small.
Right, with the recent performance improvements it's looking like it might stand on its own after all.
Great!
Honestly, it might not have needed a PEP in the first place if I had been a bit more clear about the idea earlier.
Maybe it's good to have a PEP to clear that up :)
Yeah, the PEP process has been helpful for that. :) -eric