[Python-ideas] keyword arguments everywhere (stdlib) - issue8706

[Nick Coghlan]

On Mon, Mar 5, 2012 at 4:15 AM, Guido van Rossum <guido at python.org> wrote:
> On Sun, Mar 4, 2012 at 9:20 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> If I understand correctly, there is no way to have positional-only,
>> position-or-keyword, and keyword-only in the same signature?
>
> Heh. If that's true, my '/' proposal wins:
>
> def foo(pos_only, /, pos_or_kw, *, kw_only): ...
>
> Defaults can be added to taste.

Yes, I only realised after Ethan's reply that my approach puts the
"positional only" parameters in the wrong place relative to normal
parameters (I didn't notice because I'm mainly interested in the
Mapping use case and that doesn't accept any normal parameters - just
positional only and arbitrary keywords).

So, *if* syntactic support for positional-only arguments were added, I
think Guido's syntax would be the way to do it. However, now that I've
realised the "arbitrary keyword arguments" problem can be solved
fairly cleanly by a helper function that binds the positional
arguments, I'm more inclined to just leave it alone and tell people to
just accept *args and process it that way.

OTOH, having a docs-friendly syntax, and better programmatic
introspection for the cases where it does come up would be nice,
too...

> The restrictions on args-without-defaults being unable to follow
> args-with-defaults may need to be revisited so we can combine optional
> positional arguments with required keyword arguments, if we want to
> support that.

Already done:

>>> def f(a, b=1, *, c): return a, b, c
...
>>> f(2, c=3)
(2, 1, 3)

> Nevertheless all this is pretty esoteric and I wouldn't cry if it
> wasn't added. There exist solutions for the Mapping-API problem, and a
> @positional decorator would cover most other cases.

Yep. While I do think it's a slight language wart that we can't
cleanly express all the function and method signatures that are used
by our own builtins and ABC definitions, it's a *very* minor concern
overall.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia