On Thu, Feb 3, 2022 at 4:01 PM Guido van Rossum <gu...@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
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/4625QOLXLZAAU2XNXEQM5W2JWX3FH4VM/
Code of Conduct: http://python.org/psf/codeofconduct/
