The slash "/" as used in the documentation

[Avi Gross]

Ian,

I now assume we are no longer talking about the past or even the present but
some planned future. In that future we are talking about how to define a
function with added or changed functionality. So nothing I wrote earlier
really applies because I was talking of how things did work in the absence
of the changes needed to make new functionality possible.

So let me make sure I understood you. We are talking about the function
prototype as in def fun(...) and perhaps the lambda equivalent. The user of
the function would only see changes in the help files or other documentation
but no special symbols would be used when they invoke a function, albeit new
error messages may also happen if done wrong.

The earlier messages talked about using a forward slash but you seem to use
an asterisk for the same purpose. You can use the very overloaded "*"
character as a delimiter between the parameters mentioned to the left and
any remaining ones to the right. The "=" symbol is thus now allowed on
either side of the divide and now ONLY means there is a default. 

I thought the discussion was about python, not the C API that arguably is
used as much of python is in C directly or indirectly. I thought we were
talking about updating everything at the top interpreted python levels.
Please make it clear if we are not.

Will the above functionality, if understood, break (or modify how it works)
existing python code? I mean code that only uses the asterisk to denote
multiplication, exponentiation, list expansion and dictionary expansion and
so on. 

Just based on what you wrote, maybe not. It depends on the new meaning of
not having a sole asterisk somewhere in the parameter list. If that means
evaluate old style, great. If it means something else, I won't speculate but
can picture problems.

I will talk about your C API question in another message.


-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net at python.org> On
Behalf Of Ian Kelly
Sent: Monday, February 11, 2019 1:46 AM
To: Python <python-list at python.org>
Subject: Re: The slash "/" as used in the documentation

On Sun, Feb 10, 2019 at 2:18 PM Avi Gross <avigross at verizon.net> wrote:
> 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.

My suggestion was not to allow keyword arguments to arbitrarily replace any
positional parameter, or to otherwise change argument-passing in any way.
The suggestion was to drop positional-only arguments from functions
implemented in C instead of just documenting them better. In the example
above, if you want to pass a by keyword, you would have to pass b and c by
keyword as well.
That would still be true for functions implemented in C if a, b, and c are
no longer positional-only.

> 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.

Positional arguments are allowed to have defaults, and keyword-only
arguments are allowed to not have defaults. These are all valid
syntax:

# Allows a and b to be passed either positionally or by keyword def foo(a=1,
b=2): pass

# b is keyword-only
def foo(a=1, *, b=2): pass

# Allows a and b to be passed either positionally or by keyword def foo(a,
b): pass

# b is keyword-only and has no default
def foo(a, *, b): pass

Positional-ONLY arguments are not directly supported by the language, but
they exist in the C API and can also have defaults. For example, dict.get
takes two positional-only arguments. The second argument is optional, and
its default is None.

My point is that the axis of positional-only versus positional-or-keyword
versus keyword-only, and the axis of required versus optional are entirely
separate.

> I won't go on except to say it would break lots of existing code and 
> potentially complicate new code.

Can you give an example of something that would be broken by updating C API
functions to name positional-only arguments instead of just updating them to
document that they're positional-only?
--
https://mail.python.org/mailman/listinfo/python-list