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/ZZ5QOZDOAO734SDRJGMXW6AJGAVEPUHE/
> 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/QNP7RDER74XU3DNHJP5EAZY6G6N4VYE7/
Code of Conduct: http://python.org/psf/codeofconduct/