The slash "/" as used in the documentation
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
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
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
> 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
> 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
# Allows a and b to be passed either positionally or by keyword def foo(a=1,
# 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 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
> 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?