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
