The slash "/" as used in the documentation

[Ian Kelly]

On Sun, Feb 10, 2019 at 9:34 AM Chris Angelico <rosuav at gmail.com> wrote:
>
> On Mon, Feb 11, 2019 at 2:49 AM Ian Kelly <ian.g.kelly at gmail.com> wrote:
> >
> > On Sat, Feb 9, 2019 at 1:19 PM Terry Reedy <tjreedy at udel.edu> wrote:
> > >
> > > This is the result of Python being a project of mostly unpaid volunteers.
> > >
> > > See my response in this thread explaining how '/' appears in help output
> > > and IDLE calltips.  '/' only appears for CPython C-coded functions that
> > > have been modified to use Argument Clinic.  A.C. was added, I believe,
> > > in 3.5.  Simple builtins like len would have been the first to be
> > > converted.  The math module was converted for 3.7.  There are some new
> > > conversions for 3.8 and likely some will be left for future versions.
> >
> > I'm sure there are good reasons for it like most things Python does, but I
> > can't help but wonder if working on removing the positional limitation from
> > CPython would be a better use of time.
>
> Do you ACTUALLY want to call math.sin(x=1.234) or is it purely for the
> sake of consistency? Aside from questions about the help format, what
> is actually lost by the inability to pass those arguments by name?

No, but I wouldn't object to d.get(key='foo', default=12). It's partly
about consistency, but mostly I was reacting to Terry's comments in
that a) positional-only arguments are a "limitation" and there is no
desire for the rest of Python to match CPython's behavior in this
instance, and b) it sounds like a great deal of effort is being spent
on updating all the C function signatures one at a time so that the
help string can be updated to a form that is unfamiliar and not
intuitive and not normally accessible to pure Python functions without
some arm twisting. If every function has to be updated anyway, why not
update them by fixing their signatures?