[Python-Dev] PEP 3102: Keyword-only arguments (original) (raw)

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 makeperson(**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