[Python-Dev] PEP 3102: Keyword-only arguments

Terry Reedy tjreedy at udel.edu
Fri May 5 22:19:19 CEST 2006


"Michael Urman" <murman at gmail.com> wrote in message 
news:dcbbbb410605050620s5f0844f0idb9b852bab924e7f at mail.gmail.com...

> On 5/5/06, Terry Reedy <tjreedy at udel.edu> wrote:
>> At present, Python allows this as a choice.

I made that statement in the context of comparing these syntaxes

def make_person(name, age, phone, location) # current
def make_person(*, name, age, phone, location) # possible future

for a function with required, no-default parameters.  In that context, my 
statement is true.

> Not always - take a look from another perspective:

As I wrote it, I was aware that it was not true in the alternate context 
(not perspective) of using **names.  Many true statements become otherwise 
when their context is ripped away.

> def make_person(**kwds):
>    name = kwds.pop('name', None)
>    age = kwds.pop('age', None)
>    phone = kwds.pop('phone', None)
>    location = kwds.pop('location', None)

This version gives the parameters default values and make them optional. 
The current version, ignoring error messages, of the possible future above 
is

def make_person(**names):
    name = names.pop('name')
    age = names.pop('age')
    phone = names.pop('phone')
    location = names.pop('location')
    if names: raise KeyError("Extra named args passed")

Now there are no defaults and all are required.

> This already requires the caller to use keywords,

Your version allows the seemingly senseless no-keyword call make_person().

> but results in horrid introspection based documentation.
> You know it takes some
> keywords, but you have no clue what keywords they are. It's as bad as
> calling help() on many of the C functions in the python stdlib.

Improving doc strings for C functions is a separate issue.

> So what allowing named keyword-only arguments does for us is allows us
> to document this case. That is an absolute win.

That is your opinion, whereas mine is that this generally a bad case that 
should not be written and that making it easier to write and therefore more 
likely is a loss.

Terry Jan Reedy





More information about the Python-Dev mailing list