[Python-ideas] keyword arguments everywhere (stdlib) - issue8706
ethan at stoneleaf.us
Sat Mar 3 08:54:58 CET 2012
Guido van Rossum wrote:
> On Fri, Mar 2, 2012 at 6:57 PM, Steven D'Aprano wrote:
>> 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.
> And yet people invent decorators and other hacks to insist on
> positional parameters all the time. You *can* have Too Much of a Good
> Thing, and for readability it's better if calls are consistent. If
> most calls to a function use positional arguments (at least for the
> first N positions), it's better to force *all* calls to use positional
> arguments 1-N: the reader may be unfamiliar with the parameter names.
> Also remember the subclassing issue I brought up before.
> That said, I can't come up with a syntax that I really like. Here's my
> best attempt, but I'm at most -0 on it: Have a stand-alone '/'
> indicate "all parameters to my left must be positional", just like a
> stand-alone '*' means "all parameters to my right must be keywords".
> If there's no stand-alone '*' it is assumed to be all the way on the
> right; so if there's no '/' it is assumed to be all the way on the
> left. The following should all be valid:
> def foo(/, a, b): ... # edge case, same as def foo(a, b): ...
> def foo(a, b, /): ... # all positional
> def foo(a, b=1, /): ... # all positional, b optional
> def foo(a, b, /, c, d): ... # a, b positional; c, d required and
> either positional or keyword
> def foo(a, b, /, c, d=1): ... # a, b positional; c required, d
> optional; c, d either positional or keyword
> def foo(a, b, /, c, *, d): ... # a, b positional; c required and
> either positional or keyword; d required keyword
> def foo(a, b=1, /, c=1, *, d=1): ... # same, but b, c, d optional
> That about covers it. But agreed it's no thing of beauty, so let's abandon it.
And I was just starting to like it, too. :(
Personally, I don't see it as any uglier than having the lone '*' in the
signature; although, I don't see lone '*'s all that much, whereas the
'/' could be quite prevalent.
Is this something we want? We could have a built-in decorator, like
property or staticmethod, to make the changes for us (each
implementation would have to supply their own, of course):
def foo(a, b)
Or we could use brackets or more parentheses:
def foo([a, b])
def foo((a, b))
That doesn't seem too bad...
def foo((a, b=1), c=2, *, d=3)
Since tuple-unpacking no longer happens in the definition signature, we
don't need the leading * before the parentheses.
Just my last two cents (unless the idea garners encouragement, of course ;).
More information about the Python-ideas