What justified adding the syntax for positional-only parameters to Python version 3.8?

Question

As stated in What’s New In Python 3.8 to PEP 570, that defines the syntax for only positional parameters, has been implemented.

According to PEP 570 it will be possible to use the bar in defining parameters of a function to identify that the parameters preceding this character will be only positional, in contrast to the asterisk (PEP 3102), which was already used to define only named parameters.

• What the asterisk represents in the definition of a Python function?

From version 3.8 it will be possible to do:

def foo(a, /, b, *, c):
    ...

In which:

• Parameter a should only be positional;
• Parameter b may be positional or appointed;
• Parameter c should only be appointed;

That is, the only possible ways to call the function would be foo(1, 2, c=3), with b positional, or foo(1, b=2, c=3), with b named. Any other variation that has a appointed or c positional will result in error.

Since a function, by default, already accepts positional parameters, what was the motivation to define a way to force them to be positional?

Answer 1

I think the biggest motivation is to mirror on the Python side what is already possible to do a long time ago when writing a function in C, to be used in Python. For example, functions such as print, despite having the first parameter documented as value where this first parameter cannot be passed as Named Argument - it is necessarily positional.

So, until Python 3.7, you have more flexibility to declare parameters in functions written in C than in functions written in Python - this new syntax leaves the Python side equivalent.

There are more useful things that can be found on the python-Id and python-Dev mailing lists - but I won’t remember now. If it was something really with many use cases, and you could do a lot of new things, this syntax would have been included before - I remember seeing people asking for it for several years now.

The greatest convenience is actually having functions in which the first parameters are so obvious that it has to be the first ones, that does not make their order be exchanged. (Another that I check my head was the open, but in the open the file name can be passed out of order - perhaps precisely because this syntax did not exist yet).

In addition to my informal answer, as the syntax has an approved PEP, all PEP has a session entitled "Motivation" - there is the formal motivation and can clarify this issue better and have more examples of use - https://www.python.org/dev/peps/pep-0570/#motivation

I think it’s well explained there - and they summarize the most objective benefits in 3 use cases:

• "When a function can accept any parameter with name, but can also accept a positional parameter" - this is the case of the call dict to create dictionaries: the first anonymous parameter may be another dictionary or an iterable one with keys/values, but the named parameters build a dictionary with the names of the past brackets. If the first parameter had a name (e.g. "intial" or "values"), this name could never be used as a parameter to create a key in a type call a = dict(name="Joao", values=[10,12]).

• "When a parameter has no external semantic meaning": that is, the name will only be important within the called function, as in functions that accept a single argument - and the user of that function does not have to worry about how this is implemented, simply pass any object as parameter.

• "When the parameters of an API are required and have no ambiguity" (this is the case of the "print" and "open" functions I mentioned)