PEP 570: Python Positional-Only Parameters

[njs (Nathaniel J. Smith)]

I guess a decorator-based alternative would look something like:

@positional_only_args
def len(obj):

@positional_only_args(count=1)
def dict(mapping=None, **kwargs):

This does seem like a plausible alternative to me. It’s a bit less terse, but OTOH it’s definitely easier to understand the first time you see it, and easier to document and search for. The PEP has some counter-arguments:

@pablogsal

Using decorators

It has been suggested on python-ideas^20 to provide a decorator written in Python as an implementation for this feature. This approach has the advantage that keeps parameter declaration more easy to read but also introduces an asymmetry on how parameter behaviour is declared. Also, as the / syntax is already introduced for C functions, this
inconsistency will make it more difficult to implement all tools and modules that deal with this syntax including but not limited to, the argument clinic, the inspect module and the ast module. Another disadvantage of this approach is that calling the decorated functions
will be slower than the functions generated if the feature was implemented directly in C.

I’m not sure what “asymmetry on how parameter behaviour is declared” means.

It’s true that it would require updating argument clinic, the inspect module, etc. But any change here is going to involve substantial changes across the ecosystem – I don’t think this is a serious distinction between the decorator approach and the / approach.

The biggest change with the decorator approach is that we’d want to teach help() and similar tools (sphinx) to show the full function signature, including the decorator. This would be a change from historical practice, because historically signatures were always 1 line, and now they could be multiple lines. I’m guessing this was a major factor in Argument Clinic going with /, since Argument Clinic was trying to be as minimal and unobtrusive as possible? But now that we’re talking about promoting this to a first-class language feature, we should relax that concern some. And tbh single line signatures are getting seriously crowded, between defaults, *, type hints, and now /. Splitting complex signatures into mulitple lines seems like a win for readability, and python has traditionally valued readability over terseness.

There’s no reason that calling the decorated functions has to be any slower. It would be if we add the constraint that we’re not allowed to change the interpreter, but that constraint would rule out the / notation entirely, so it’s hardly a fair comparison :-). The implementation could be in C in both cases, with the decorator just setting some metadata on the function object to be consumed by the underlying function call machinery.

So the PEP’s arguments against the decorator approach seem very weak to me. Given that this alternative is coming up multiple times in the thread, it would be nice if the PEP could at least expand this section to address it more seriously.

IMO, if this is something that we expect people to use frequently, say in >10% of all function signatures, then the / syntax is better, and if it’s more of a niche feature that’s primarily used to handle the special needs of functions like float and dict, then the decorator approach is better.