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

[Chris Rebert]

On Fri, Mar 2, 2012 at 6:57 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> Ethan Furman wrote:
>> Guido van Rossum wrote:
>>> On Fri, Mar 2, 2012 at 2:49 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>>>> Terry Reedy wrote:
>>>>> On 3/2/2012 3:32 PM, Ethan Furman wrote:
>>>>>
>>>>>> So something like:
>>>>>>
>>>>>> def ord(char, ?):
>>>>>>
>>>>>> def split(self, char, ?, count)
>>>>>>
>>>>>> def canary(breed, ?, color, wingspan, *, name)
>>>>>
>>>>> That is probably better than using '$' or directly tagging the names.
>>>>
>>>> I chose '?' because it has some similarity to an incompletely-drawn 'p',
>>>> and
>>>> also because it suggests a sort of vagueness, as in not being able to
>>>> specify the name of the argument.
>>>
>>> I'd rather not start using a new punctuation character for this one
>>> very limited purpose; it might prevent us from using ? for some other
>>> more generic purpose in the future.
>>>
>>> Alternative proposal: how about using '/' ? It's kind of the opposite
>>> of '*' which means "keyword argument", and '/' is not a new character.
>>
>> So it would look like:
>>
>>  def ord(char, /):
>>
>>  def split(self, char, /, count)
>>
>>  def canary(breed, /, color, wingspan, *, name)
>>
>> I think I like that better -- it stands out, and it looks like a barrier
>> between the positional-only and the positional-keyword arguments.
>
> Urrggg, ugly and hard to read. Imagine, if you will:
>
> def spam(x, /, y, /, z, /, a=2/3, /):
>    ...
>
> Placing the tag after the argument as an extra parameter is not the right
> approach in my opinion.

I don't believe that's what the proposal is anyway. Note Ethan's
"barrier" comment.

> It's excessively verbose, and it puts the tag in the
> wrong place: as you read from left-to-right, you see "normal argument, no,
> wait, it's positional only". The tag should prefix the name.
>
> With keyworld-only arguments, the * parameter is special because it flags a
> point in the parameter list, not an individual parameter: you read "normal
> arg, normal arg, start keyword-only args, keyword-only arg, ...".

That's in the same vein as what I understand the proposal to be. "/"
would flag "end of positional-only args"; there's effectively an
implicit leading "/" if you don't use one in a function's definition.

<snip>
> Personally, I think this is somewhat of an anti-feature. Keyword arguments
> are a Good Thing, and while I don't believe it is good enough to *force* all
> C functions to support them, I certainly don't want to discourage Python
> functions from supporting them.

+1

I can see not modifying every single C implementation as it's for
little gain, and in a bunch of cases concerns 1-or-2-argument
functions which are arguably worth special-casing. But making the
function definition syntax even more complicated (we have annotations
now, remember?) just to allow forcing calls to be (slightly) more
restrictive/opaque? Hard to get on board with that.

Cheers,
Chris