The slash "/" as used in the documentation
avigross at verizon.net
Sun Feb 10 16:15:17 EST 2019
I would appreciate another pointer to the documentation explaining what was
done and why as I deleted the earlier discussion.
> Aside from questions about the help format, what is actually lost by the
> 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
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 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:
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
def func(a, b, c, d=1, e=2, key_a=None):
if a == ... :
a = key_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(...,2,3,key_a="keyed up")
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.
From: Python-list <python-list-bounces+avigross=verizon.net at python.org> On
Behalf Of Chris Angelico
Sent: Sunday, February 10, 2019 11:32 AM
To: Python <python-list at python.org>
Subject: Re: The slash "/" as used in the documentation
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
> > 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
> 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?
More information about the Python-list