[Python-Dev] Extending tuple unpacking

[Michael Chermside]

Steve Holden writes:
> I do feel that for Python 3 it might be better to make a clean
> separation between keywords and positionals: in other words, of the
> function definition specifies a keyword argument then a keyword must be
> used to present it.
>
> This would allow users to provide an arbitrary number of positionals
> rather than having them become keyword arguments. At present it's
> difficult to specify that.

Antoine Pitrou already responded:
> Do you mean it would also be forbidden to invoke a "positional" argument
> using its keyword? It would be a huge step back in usability IMO. Some
> people like invoking by position (because it's shorter) and some others
> prefer invoking by keyword (because it's more explicit). Why should the
> implementer of the API have to make a choice for the user of the API ?

I strongly agree with Antoine here, but the combination of "keyword
arguments after the star":

> foo(a, b, c=1, *args, d=2, e=5, **kwargs)
>     ^^^^^^^^^         ^^^^^^^^
>     positional        only with kw
>     or with kw

with "star without a name":

>     def f(a, b, c=default, *, foo=1, bar=2): pass
>
> Here, c is a positional argument with a default value, while foo and bar are
> forced to be keyword arguments.

is quite tempting. It satisfies Steve by allowing the implementer of the
function to require keyword arguments. It satisfies Antoine and myself
by also allowing the implementor of the function to permit positional OR
keyword use, and making this the default behavior. It is logically
consistant. There's just one big problem that I know of:

Guido writes:
> I've always wanted to write that as
>
>     f(a, b, *args, foo=1, bar=2, **kwds)
>
> but the current grammar doesn't allow it.

Hmm.... why doesn't the current grammar allow it, and can we fix that?
I don't see that it's a limitation of the one-token-lookahead, could
we permit this syntax by rearanging bits of the grammer?

-- Michael Chermside