Repository navigation
[C API] Add PyObject_GetDict() function #139852
Description
Activity
- addedtype-featureA feature request or enhancementA feature request or enhancementinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)
on Oct 9, 2025 - added a commit that references this issue
on Oct 9, 2025 I don't think this is a good idea.
There is reason this function is private. Using this function is potentially dangerous, the name is misleading and it is may be perpetuating a misunderstanding of how Python objects are implemented.
It is dangerous, because assigning directly to the pointer returned by this function could result in the object and its
__dict__getting out of sync.
Its name is misleading as it suggests that it is getting a pointer, without side effects, and that pointer can be written to.
It also perpetuates the idea that all objects have a dictionary (at the C level), and that accessing that dictionary is cheap.Just because something is widely used does not mean we should make it public. We should be helping extension authors to write good code, not perpetuating their mistakes.
Why are C extensions using this method anyway? If they are using it just to get the object's dictionary for legitimate reasons, then we should add a
PyObject_GetDictfunction for that purpose.Also, we should probably change the docs for
PyObject_GenericGetDictto make it clear that it is for implementing the__dict__slot, not to be called as an API.Reacted by Petr ViktorinThis function is also broken on free-threading because free-threading stores and reads dict pointer atomically, it is not safe to read the dict pointer directly as returned by this function.
Why are C extensions using this method anyway? If they are using it just to get the object's dictionary for legitimate reasons, then we should add a PyObject_GetDict function for that purpose.
For various reasons, see for example #139854 (comment). Should we add a PyObject_SetDict() function as well?
Should we add a PyObject_SetDict() function as well?
Not with the current evidence. I'd be interested to know if
SWIG_PYTHON_SLOW_GETSET_THISis helpful nowadays -- ideallyPyObject_SetAttrwould be all they need.One of Cython's uses of this I think is duplicating
PyType_Lookupso could probably go away if you provided that.I think in general
PyObject_GetDictwould be more useful thanGetDictPtr.At least some of the time I'm using the dict rather than
GetAttr/SetAttrbecause I can doPyDict_SetDefaultand I know it'll be thread safe. That's very useful for lazy initialization, and is something you can't easily replicate without the dict.Reacted by Victor StinnerOne of Cython's uses of this I think is duplicating PyType_Lookup so could probably go away if you provided that.
I created #139847 to add
PyType_Lookup()function.I think in general PyObject_GetDict would be more useful than GetDictPtr.
Ok, I created #139968 to add
PyObject_GetDict()function. It's similar toPyObject_GenericGetDict()but has a different API and doesn't raise an exception if the__dict__doesn't exist.- changed the title
[-][C API] Add PyObject_GetDictPtr() function[/-][+][C API] Add PyObject_GetDict() function[/+]on Oct 11, 2025 I created capi-workgroup/decisions#82 for the C API Working Group.
And the decision is to not add the
PyObject_GetDict()function. So I close the issue.
Feature or enhancement
There is a private
_PyObject_GetDictPtr()function which is used by 30 projects of the PyPI top 15,000 projects:I propose to make the function public with a different API to no longer ignore errors silently.
UPDATE: I now propose adding
PyObject_GetDict()(PyObject **dictparameter), instead ofPyObject_GetDictPtr()(PyObject ***dict_ptrparameter).Linked PRs