Ian, I want to make sure we are talking about the same things in the same ways. I will thus limit my comments in this message.
If efficiency is your major consideration, then using only positional arguments of known types you can place on the stack and optimize at compile time may be a great way to go. It is not the way python generally goes as it supports objects at run time that can be of any type and in many cases allows any number of arguments to a function. Python was designed till recently in a way that valued some more innovative methods and that included allowing a combination of positional and keyword arguments. The positional arguments can still be called with keyword but only if moved beyond any other positional arguments. What evolved is NOT the only way I have seen this done. But what I see now is not what you are describing in some ways. If you want to talk about recent or planned changes, fine. But make that clear. I was talking about how in the past positional arguments did not have defaults available at the def statement level. I was talking about how use of the symbol "=" in the context of defining function parameters had multiple meanings. It not only established that the parameter accepted a keyword but also provided a default. The allowed syntax required a default, even if it was None. I mean the following fails: >>> def func(a,b=): pass SyntaxError: invalid syntax If in the future (or some other language) you want to allow some way of assigning a default to positional arguments, fine. What I see today does not. So if I understand you, there is a proposal or even plan to change some of the current functionality. I still have not seen anyone post a reference as requested. I am very open to seeing what people are considering or maybe even implementing and in what ways it may not be compatible with present functionality. -----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