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....@python.org> On Behalf Of Ian Kelly Sent: Monday, February 11, 2019 1:46 AM To: Python <python-list@python.org> Subject: Re: The slash "/" as used in the documentation On Sun, Feb 10, 2019 at 2:18 PM Avi Gross <avigr...@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 -- https://mail.python.org/mailman/listinfo/python-list
