On Thu, Feb 3, 2022 at 4:01 PM Guido van Rossum <guido@python.org> wrote:
Why not read through some of that code and see what they are doing with it?
Yep, I'm planning on it.
I imagine one advantage is that _Py_IDENTIFIER() can be used entirely local to a function.
Yeah, they'd have to put something like this in their module init: state->partial_str = PyUnicode_InternFromString("partial"); if (state->partial_str == NULL) { return NULL; }
E.g. (from _operator.c):
_Py_IDENTIFIER(partial); functools = PyImport_ImportModule("functools"); if (!functools) return NULL; partial = _PyObject_GetAttrId(functools, &PyId_partial);
That's convenient since it means they don't have to pass module state around.
I might call that cheating. :) For an extension module this means they are storing a little bit of their state in the runtime/interpreter state instead of in their module state. Is there precedent for that with any of our other API? Regardless, the status quo certainly is simpler (if they aren't already using module state in the function). Without _Py_IDENTIFER() it would look like: functools = PyImport_ImportModule("functools"); if (!functools) return NULL; my_struct *state = (my_struct*)PyModule_GetState(module); if (state == NULL) { Py_DECREF(functools); return NULL; } partial = PyObject_GetAttr(functools, state->partial_str); If they are already using the module state in their function then the code would be simpler: functools = PyImport_ImportModule("functools"); if (!functools) return NULL; partial = PyObject_GetAttr(functools, state->partial_str); -eric