On Sun, Feb 10, 2019 at 9:34 AM Chris Angelico <ros...@gmail.com> wrote: > > On Mon, Feb 11, 2019 at 2:49 AM Ian Kelly <ian.g.ke...@gmail.com> wrote: > > > > On Sat, Feb 9, 2019 at 1:19 PM Terry Reedy <tjre...@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? -- https://mail.python.org/mailman/listinfo/python-list