On Thu, Feb 3, 2022 at 6:37 AM Victor Stinner <vstinner@python.org> wrote:
By the way, Argument Clinic now produces way faster calling conventions than hand-written METH_VARARGS with PyArg_ParseTuple(). It would be make this tool available to 3rd party projects.
Either extract it and put it on PyPI, but it means that Python will need to Python and pip install something to build itself... not good?
Since we check in the generated source you only need Python installed while developing CPython, not to build it. And since that's already a requirement to build the docs, freeze code, etc. I don't think that's an unreasonable requirement. We also don't have to break Argument Clinic out of our repo just to make it available externally. There's nothing saying we can't have a subdirectory of code that we directly rely on and publish separately for our development needs. Could even add blurb into the repo that way if we wanted to. -Brett
Or we can add it to stdlib. IMO we need to write more tests and more documentation. Right now, test_clinic is "light". Another issue is that it requires on the currently privte _PyArg_Parser structure. By the way, this structure is causing crashes if sub-interpreters are run in parallel (one GIL per interpreter) because of the _PyArg_Parser.kwtuple tuple of keyword parameter names (tuple of str).
If Eric's tool becomes successful inside CPython, we may consider to make it available to 3rd party projects as well. Such tool and Argument Clinic and not so different than Cython which generates C code to ease the development of C extensions modules.
Victor
On Thu, Feb 3, 2022 at 7:50 AM Inada Naoki <songofacandy@gmail.com> wrote:
+1 for overall.
On Thu, Feb 3, 2022 at 7:45 AM Eric Snow <ericsnowcurrently@gmail.com>
wrote:
I'd also like to actually get rid of _Py_IDENTIFIER(), along with other related API including ~14 (private) C-API functions. Dropping all that helps reduce maintenance costs. However, at least one PyPI project (blender) is using _Py_IDENTIFIER(). So, before we could get rid of it, we'd first have to deal with that project (and any others).
It would be nice to provide something similar to _PY_IDENTIFIER, but designed (and documented) for 3rd party modules like this.
``` typedef struct { Py_IDENTIFIER(foo); ... } Modstate; ... // in some func Modstate *state = (Modstate*)PyModule_GetState(module); PyObject_GetAttr(o, PY_IDENTIFIER_STR(state->foo)); ... // m_free() static void mod_free(PyObject *module) { Modstate *state = (Modstate*)PyModule_GetState(module); Py_IDENTIFIER_CLEAR(state->foo); } ```
-- Inada Naoki <songofacandy@gmail.com> _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/ZZ5QOZDO... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/QNP7RDER... Code of Conduct: http://python.org/psf/codeofconduct/