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

[Arnaud Delobelle]

On 2 March 2012 19:28, Guido van Rossum <guido at python.org> wrote:
> On Fri, Mar 2, 2012 at 4:13 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Fri, Mar 2, 2012 at 6:43 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>>> +1 on adding keyword arguments to built-in methods and functions where they
>>> would help readability, e.g str.find(c, start=23), even if this happens in a
>>> ad-hoc fashion.
>>
>> Indeed, this is the approach we have taken to date. For example,
>> str.split() recently gained keyword support for 3.3 because
>> "text.split(maxsplit=1)" is less cryptic than "text.split(None, 1)".
>>
>> It makes the most sense when at least one of the following holds:
>> - the second argument accepts a number that is unclear if you're not
>> familiar with the full function signature
>> - the earlier arguments have sensible default values that you'd prefer
>> not to override
>>
>> So +1 on declaring "make X support keyword arguments"
>> non-controversial for multi-argument functions, +0 on also doing so
>> for single argument functions, but -0 on attempting to boil the ocean
>> and fix them wholesale.
>
> Hm. I think for many (most?) 1-arg and selected 2-arg functions (and
> rarely 3+-arg functions) this would reduce readability, as the example
> of ord(char=x) showed.
>
> I would actually like to see a syntactic feature to state that an
> argument *cannot* be given as a keyword argument (just as we already
> added syntax to state that it *must* be a keyword).

There was a discussion about this on this list in 2007.  I wrote some
decorators to implement it this functionality.  Here's one at

http://code.activestate.com/recipes/521874-functions-with-positional-only-arguments/?in=user-4059385

(note that it didn't attract a lot of attention !).  The recipe also
refers to the original discussion.

-- 
Arnaud