On Mon, Feb 11, 2019 at 6:49 PM Ian Kelly <ian.g.ke...@gmail.com> wrote: > > On Mon, Feb 11, 2019 at 12:19 AM Terry Reedy <tjre...@udel.edu> wrote: > > The pass-by-position limitation is not in CPython, it is the behavior of > > C functions, which is the behavior of function calls in probably every > > assembly and machine language. Allowing the flexibility of Python > > function calls take extra code and slows function calls. > > > > math.sin, for instance, is a fast-as-possible wrapper around the C math > > library sin function. It extracts the C double from the Python float, > > calls C sin, and returns the returned C double wrapped as a Python > > float. Coredevs decided that being able to call math.sin(x=.33333) is > > not worth the resulting slowdown. I am rather sure that heavy users of > > the math module would agree. > > For math.sin, sure, but what about, say, list.index? Here's the start > of the implementation: > > static PyObject * > listindex(PyListObject *self, PyObject *args) > { > Py_ssize_t i, start=0, stop=Py_SIZE(self); > PyObject *v; > > if (!PyArg_ParseTuple(args, "O|O&O&:index", &v, > _PyEval_SliceIndex, &start, > _PyEval_SliceIndex, &stop)) > > > This is already paying the cost of not using C-style positional > function arguments, but then it only takes an argument tuple, so it > can't take keyword arguments anyway. Why?
How much of a performance penalty are you willing to accept for this? It would apply to every C-implemented function, including tiny and common ones like 1+2, just in case someone wanted to write int.__add__(self=1, value=2). Try to pitch this to sysadmins and app authors: "CPython 3.8 will be 3% slower, but you can pass keyword args to dunders now!" ChrisA -- https://mail.python.org/mailman/listinfo/python-list