LWN: Comments on "Positional-only parameters for Python"

Positional-only parameters for Python

tildeswinton — Fri, 19 Apr 2019 19:32:35 +0000

This seems to be a proliferation of the current PEP trend of adding complex functionality for edge cases. I would almost argue that many of these newer PEPs are the Python equivalent of giving a TEDx talk or presenting at another well known conference: there seems to be a stronger desire to have it as a bullet point on their resume than a desire to leave a meaningful, lasting impact.

Positional-only parameters for Python

dbaker — Fri, 12 Apr 2019 20:41:25 +0000

Which is just so weird to me :)

Positional-only parameters for Python

mgedmin — Thu, 11 Apr 2019 09:39:52 +0000

And for extra fun, _ has a special meaning in the REPL (it contains the value of the last expression).

$ python3
Python 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 2 + 2
4
>>> print("hi")
hi
>>> _
4

Positional-only parameters for Python

k8to — Thu, 11 Apr 2019 02:11:58 +0000

It seems valuable to have a choice on whether to expose the names or not. However, there are many modules where the docs don't talk about the argument names, but keyword arguments make the consuming code vastly more readable.

I think the fact that the arg names are exposed by default is essentially a good accident that forces interfaces to be a bit more usable than they are by default.

Amusingly I went to a good deal of trouble in some code I made to make the args keyword-only without making the implementation of the callsites harder to read. I had explicit documentation of how calls were required to be made, but used inspection to enforce it. I could used def func(**kwargs) but manually coding all the dispatch would have been really unfortunate.

Positional-only parameters for Python

quotemstr — Wed, 10 Apr 2019 22:08:43 +0000

One problem is API signature ambiguity. Say I have a def foo(bar): return bar +1. People right now are allowed to call foo as foo(5) or foo(bar=5). Now suppose I want to refactor foo as "def foo(qux):return 1+qux". Is the change of the argument name a breaking API change? Only if w allow keyword argument specification for bar! Right now, we have to treat argument names as part of a function's signature, and I think that's too constricting.

Positional-only parameters for Python

yootis — Wed, 10 Apr 2019 20:52:07 +0000

Why is it ever actually necessary to prevent the use of keyword arguments? The article mentions "what if the API changes", but to me that's all the more reason to use keyword arguments. At least you'd detect the problem. Forcing positional arguments sounds dangerous to me.

Positional-only parameters for Python

juliank — Wed, 10 Apr 2019 17:57:28 +0000

Using _ for things to ignore is fine until you want to introduce gettext as _ :D

Positional-only parameters for Python

dbaker — Wed, 10 Apr 2019 16:35:32 +0000

not only that, _ is the conventional name of any variables that you're going to ignore. Which is really handy for a lot of things;

iterating over containers of containers:

for a, b, _ in [(1, 'a', []), (2, 'b', [])]: ...

for functions that need to fulfill an interface:

def f1(f: str, *, opt: bool = False):
def f2(f: str, **_):

myval = [f(myval, opt=True) for f in [f1, f2]]

with the python3 partial container explosion syntax:

a, b, *_ = (1, 2, 3, 4)

and a bunch of other cases.

Positional-only parameters for Python

FLHerne — Wed, 10 Apr 2019 13:16:59 +0000

That's already valid syntax - `_` is an acceptable name in Python, so it's identical to `def fun(name, *args)`.

>>> def fun(name, *_):
>>> print(_)
...
>>> fun("A", "B", "C")
('B', 'C')

Positional-only parameters for Python

LtWorf — Wed, 10 Apr 2019 11:02:25 +0000

Breaking changes in languages are bad.

Positional-only parameters for Python

rgb — Wed, 10 Apr 2019 10:59:38 +0000

How about

def fun(name, *_):
...

Positional-only parameters for Python

foom — Wed, 10 Apr 2019 06:38:52 +0000

But that's exactly the problem: There's no such thing as a "positional argument" to a function defined as Python (vs C) until the new PEP.

Maybe you meant that all _required_ arguments should have been made positional only? But, then what about optional arguments? Those must allow keyword calls?

Positional-only parameters for Python

niner — Wed, 10 Apr 2019 06:14:01 +0000

Seems to me like the real solution would be to just not allow passing positional arguments by keyword, i.e. keeping them completely separate. That would get rid of the renaming issue, the subclassing issue, the "fmt" issue and all inconsistencies. It would also adhere more to the Python design principles, most of all to:
Special cases aren't special enough to break the rules.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
If the implementation is hard to explain, it's a bad idea.

Of course such a change would be quite backwards incompatible. If only they had used the one chance they got to make such changes for actually fixing the language...