The slash "/" as used in the documentation

Chris Angelico rosuav at gmail.com
Mon Feb 11 02:55:32 EST 2019


On Mon, Feb 11, 2019 at 6:49 PM Ian Kelly <ian.g.kelly at gmail.com> wrote:
>
> On Mon, Feb 11, 2019 at 12:19 AM Terry Reedy <tjreedy at 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


More information about the Python-list mailing list