On Thu, Feb 3, 2022 at 2:50 PM Eric Snow <[email protected]> wrote:
> On Wed, Feb 2, 2022 at 11:50 PM Inada Naoki <[email protected]> > wrote: > > It would be nice to provide something similar to _PY_IDENTIFIER, but > > designed (and documented) for 3rd party modules like this. > > I suppose I'd like to know what the value of _Py_IDENTIFIER() is for > 3rd party modules. They can already use PyUnicode_InternFromString() > to get a "global" object and then store it in their module state. I > would not expect _Py_IDENTIFIER() to provide much of an advantage over > that. Perhaps I'm missing something? > > If there is a real benefit then we should definitely figure out a good > public API for it (if the current private one isn't sufficient). I > won't be authoring that PEP though. :) > Why not read through some of that code and see what they are doing with it? I imagine one advantage is that _Py_IDENTIFIER() can be used entirely local to a function. 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. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/G5Y7DROKELUQYSVMHQBUIUMZOPODXCXF/ Code of Conduct: http://python.org/psf/codeofconduct/