[Python-ideas] PEP for issue2292, "Missing *-unpacking generalizations"

[Joshua Landau]

On 7 July 2013 07:26, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> On 6 Jul, 2013, at 6:30, Joshua Landau <joshua.landau.ws at gmail.com> wrote:
>
>> The PEP is attached. I'm not sure if I've covered the basics, but it's a try.
>>
>> If anyone knows how to get the patch (from the bug report) working, or
>> where to find http://code.python.org/python/users/twouters/starunpack
>> after code.python.org was deleted in favour of hg.python.org (which
>> seems not to have it), it'd be nice to know.
>
> As you already noted in your proposal the proposed changes to function
> definitions are not backward compatible:

I wrote the PEP, but I tried not to add any ideas of my own (other
than clarifications). Whilst I failed at that -- function signature
changes weren't actually in the original implementation -- it's worth
keeping me separate from those who proposed the ideas and did the bulk
of the work for them. I just liked the idea so am trying to nudge it a
bit with this.

>    def func(*args, foo): pass
>
> Currently 'foo' is a required keyword argument, with your change it
> would be just another positional only argument. How would you define
> keyword-only arguments with your proposal? The only alternative I could
> come up with is an extension of how you currently define keyword arguments
> without having a '*args' argument:
>
>     def func(*args, *, foo): pass
>
> This however is currently not valid (SyntaxError) and would therefore
> make it a lot harder to write functions with keyword-only arguments that
> work both before and after your proposed change.

As I replied to someone else, "I also seem to have magically created
this - it seems not to be in the original implementation. Hence if
no-one supports the idea, and since I'm not very attached to it,
there's no loss in letting it go."

That's a good counter-argument, and no-one seems to support changes to
function definitions, so I'll go with the flow and remove it. It's not
needed for the rest of the PEP to make sense.

I'll probably update the PEP tomorrow, for some skewed definition of
tomorrow (I don't really have a sleep-cycle ATM) but how to define
function-call grammar is still undefined so I'll lay out the two
alternatives that currently make sense to me.