Chris, I would appreciate another pointer to the documentation explaining what was done and why as I deleted the earlier discussion.
You ask: > Aside from questions about the help format, what is actually lost by the inability > to pass those arguments by name? I am not sure how python implements some of the functionality it does as compared to other languages with similar features. But I note that there are rules, presumably some for efficiency, such as requiring all keyword arguments to be placed after the last positional argument. I mean I can call func(a,b,c,d=1,e=2) but not func(a,b,d=1, c, e=2). So if you allowed a keyword to optionally be used for any positional argument other than the last, c, would it not require a change in this rule? I mean func(a="invalid",b,c,d=1,e=2) would violate the rule and so would making b a keyword version. In my example, and for this reason only, maybe c could work. And note the impact IF ALLOWED on the existing and new programs that allow a variable number of arguments of the form func(*args, **kwargs) when they evaluate. The previous model was that args would be a sequence of the arguments you could index so args[0] would be the first, or that you can pop off the front and use. If any of the previously un-named arguments can now entered with a keyword, are they now placed in args or in the dictionary kwargs? If in kwargs, the program now needs to know to look there in addition to the command line. If it was the first argument and is no longer in args, the second and further arguments would either be shifted over and be used wrong or you need a placeholder. The original motivation for keyword arguments included the concept of specifying a default if not used. Positional arguments have no default. Similarly, they are required if explicitly named in the function definition. So we are intermingling multiple concepts in the previous design. I won't go on except to say it would break lots of existing code and potentially complicate new code. Let me add a dumb suggestion. Anyone who desperately wants to name the parameters has a rather strange option they can do now. Very imperfect but consider the function prototype I have been using for illustration: func(a,b,c,d=1,e=2) It requires three positional arguments. What if you implement your code so some special values mean that you are going to pass along "a" as "key_a" instead. You can use something like None or the ellipsis(...) to signal this as in: def func(a, b, c, d=1, e=2, key_a=None): if a == ... : a = key_a print(a) The above does nothing but illustrates a WAY to allow a keyword implementation by using one or more placeholders as you can do the same gimmick for b and c. Here is how it runs if you use the positional arg, or an ellipsis and then a keyword or an ellipsis and accept the default for the keyword: >>> func(1,2,3) 1 >>> func(...,2,3,key_a="keyed up") keyed up >>> func(...,2,3) None So could you re-implement processing in a NEW language to allow different handling. I am guessing you could. Again, other languages currently do things their own way. But for compatibility, I can see why they may be patching and documenting what IS. And note you could create an amazingly annoying language where each parameter is specified as having umpteen attributes like it has to be the second un-named argument and of a restricted number of types and if it has a keyword it can be abbreviated as short as some string and then should it be placed in position 2 and does it have a default and who knows what more. Avi -----Original Message----- From: Python-list <python-list-bounces+avigross=verizon....@python.org> On Behalf Of Chris Angelico Sent: Sunday, February 10, 2019 11:32 AM To: Python <python-list@python.org> Subject: Re: The slash "/" as used in the documentation 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? ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list