On Thu, 2022-02-03 at 15:32 +0100, Victor Stinner 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?
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.
It would be great to have a clear API available to store constants like this, for NumPy these currently are: * mainly interned strings * Some custom singletons which are currently defined in Python (including exceptions, but not so important) * Python functions that are called from C. I am pretty sure that some of the places that do not have module state available, but likely many (most?) of them could be refactored (e.g. a converter function that needs a singleton: it isn't terrible to manually converter later on). Many will be in methods. It would be great to have a "blessed" solution for kwarg parsing. I had shunned argument clinic because it felt too internal, probably CPython specific, and it seemed like you basically need to check in the generated code for each supported Python version... The current solution in NumPy [1] is a bit limited and uses those statics to store the interned strings. And it duplicates Python logic that would be nice to not duplicate. Cheers, Sebastian [1] For the curious, the API for NumPy looks like this: /* * Declare a function static struct for string creation/interning * and caching other prep (generated on the first call. * `npy_parse_arugments` is a macro, but only to insert the cache name) */ NPY_PREPARE_ARGPARSER; if (npy_parse_arguments(funcname, args, len_args, kwnames "", NULL, &pos_only_obj, "kw1", &Converter, &kw1_val, "|kw2", NULL, &kw2_obj, "$kw_only1", NULL, &kw_only2_obj, NULL, NULL, NULL) < 0) { return NULL; } So it is very limited to converters (e.g. no "i" or "!O" convenience), since we don't use that much anyway. One annoyance is that "i" and "s" don't have a clear "converter" and that converters can't raise an error message that includes the function and parameter name.
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/