Repository navigation
[C API] Add PyObject_GetDict() function #139852
Description
Feature or enhancement
There is a private _PyObject_GetDictPtr() function which is used by 30 projects of the PyPI top 15,000 projects:
- accesscontrol (7.2)
- acquisition (6.1)
- backports_datetime_fromisoformat (2.0.3)
- casadi (3.7.2)
- catboost (1.2.8)
- cvxpy (1.7.2)
- cvxpy_base (1.7.2)
- cython (3.1.4)
- extensionclass (6.0)
- frozendict (2.4.6)
- gamsapi (51.1.0)
- gdal (3.11.4)
- gevent (25.9.1)
- guppy3 (3.1.5)
- htseq (2.0.9)
- hunter (3.9.0)
- ihm (2.7)
- jpype1 (1.6.0)
- m2crypto (0.45.1)
- mecab-ko (1.0.1)
- mecab_python3 (1.0.10)
- mupdf (1.21.1.20230112.1504)
- passagemath_standard_no_symbolics (10.6.26)
- persistence (5.1)
- persistent (6.1.1)
- pybind11 (3.0.1)
- pygdal (3.6.4.11)
- pygraphviz (1.14)
- python_crfsuite (0.9.11)
- sentencepiece (0.2.1)
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 **dict parameter), instead of PyObject_GetDictPtr() (PyObject ***dict_ptr parameter).
Activity
pythongh-139852: Add PyObject_GetDictPtr() function
markshannon commentedon Oct 10, 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.kumaraditya303 commentedon Oct 10, 2025
This 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.
vstinner commentedon Oct 10, 2025
For various reasons, see for example #139854 (comment). Should we add a PyObject_SetDict() function as well?
encukou commentedon Oct 10, 2025
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.da-woods commentedon Oct 11, 2025
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.vstinner commentedon Oct 11, 2025
I created #139847 to add
PyType_Lookup()function.pythongh-139852: Add PyObject_GetDict() function
pythongh-139852: Add PyObject_GetDict() function
vstinner commentedon Oct 11, 2025
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.[-][C API] Add PyObject_GetDictPtr() function[/-][+][C API] Add PyObject_GetDict() function[/+]vstinner commentedon Nov 17, 2025
And the decision is to not add the
PyObject_GetDict()function. So I close the issue.