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

Terry Reedy tjreedy at udel.edu
Tue May 2 04:12:31 CEST 2006


""Martin v. Löwis"" <martin at v.loewis.de> wrote in message 
news:445644D1.3050200 at v.loewis.de...
> You weren't asking for a reason, you were asking for an example:

No wonder we weren't connecting very well.  You somehow have it backwards. 
'Why' means "for what reason".  But to continue with examples:

my way to call your example (given the data in separate variables):
  make_person(name, age, phone, location)
your way:
  make_person(name=name, age=age, phone=phone, location = location)

my way (given the data in one sequence):
  make_person(*person_data)
your way:
  make_person(name=person_data[0], age=person_data[2],
      phone=person_data[3], location=person_data[3])

> Because there should be preferably only one obvious way to call that
> function.

It is a feature of Python that arguments can usually be matched to 
parameters either by position or name, as the *caller* chooses.  But if you 
want to (ab)use (my opinion) the 'one obvious way' mantra to disable that , 
then 'my way' above is obviously the more obvious way to do so ;-).  It is 
to me anyway.  Try typing the 'your way' version of the second pair without 
making and having to correct typos,

>Readers of the code should not need to remember the
> order of parameters,

And they need not; it is right there in front of them.  As for writers, 
modern IDEs should try to list the parameter signature upon typing 'func('.

> instead, the meaning of the parameters should
> be obvious in the call.

With good naming of variables in the calling code, I think it is.

 > I don't *want* callers to pass these
> parameters positionally, to improve readability.

The code I write is my code, not yours, and I consider your version to be 
less readable, as well as harder to type without mistake.  Do you think 
Python should be changed to prohited more that one, or maybe two named 
positional parameters?

Terry Jan Reedy





More information about the Python-Dev mailing list