[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