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

Chris Rebert pyideas at rebertia.com
Sat Mar 3 04:31:56 CET 2012

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.

> 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.


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.


More information about the Python-ideas mailing list