What value should be passed to make a function use the default argument value?

[Fredrik Lundh]

Not sure exactly what is going on / being argued about in this
> thread

I'm describing best practices based on long experience of using and
developing and teaching and writing about Python stuff. Others have
other priorities, it seems.

> This doesn't say anything positive or negative about the practice in
> question

The tutorial tends to describe mechanisms, not best practices, and it
also assumes prior programming experience. After all, basic stuff like
"minimize coupling" and "don't depend on implementation artifacts" apply
to all software engineering, not just Python.

</F>

 

[Antoon Pardon]

Not sure exactly what is going on / being argued about in this thread but HTH :?

http://docs.python.org/tut/node6.html

This doesn't say anything positive or negative about the practice in
question, but does point out that it is possible. I think it is a
reasonable assumption that if it isn't necessary, most users will
elide the keywords.

What I am argueing is that it is very natural for python programmers to
assume that keyword arguments will work if they see a signature. IMO
if a python programmer sees something like:

abs(x)

It is very natural to envision a corresponding def statement like:

def abs(x):

and a python function written like this will work if called as
follows:

abs(x=5)

IMO this is a very natural thought process for a python programmer.
So a python programmer seeing the first will tend to expect that
last call to work.

Now frederic claims that the general rule is different. Now I'm
perfectly happy to accept that those who write the documentation
do so based aacording to the rule frederic stated (you can't/shouldn't
use a parameter as a keyword argument unless explictly stated in the
documentation), but that doesn't contradict that readers may have
different expectations.

 

[Antoon Pardon]

I'm describing best practices based on long experience of using and
developing and teaching and writing about Python stuff. Others have
other priorities, it seems.

I just think you shouldn't assume the readers of the documentation
are aware of best practices.

 

[Fredrik Lundh]

IMO this is a very natural thought process for a python programmer.
So a python programmer seeing the first will tend to expect that
last call to work.

on the other hand, if a Python programmer *writes* some code instead;
say, a trivial function like:

def calculate(a, b):
# approximate; gonna have to fix this later
return a + b * 1.2

chances are that he did *not* intend this to be called as

calculate(a=1, b=2)

or, for that matter,

calculate(b=2, a=1)

or

calculate(1, b=2)

just because the Python calling machinery currently happens to allow
that. And chances are that he did *not* expect to be stuck with those
argument names for the foreseeable future, just because someone else
decided to interpret things in the most literal way they possibly could.

Python 2.X doesn't provide convenient support for distinguishing between
accidental and intentional argument names when you implement a function;
that's a wart, not a feature, and it may be addressed in 3.X.

</F>

 

[Antoon Pardon]

on the other hand, if a Python programmer *writes* some code instead;
say, a trivial function like:

def calculate(a, b):
# approximate; gonna have to fix this later
return a + b * 1.2

chances are that he did *not* intend this to be called as

calculate(a=1, b=2)

or, for that matter,

calculate(b=2, a=1)

or

calculate(1, b=2)

Well maybe he didn't intend that, but how is the reader of the
documentation to know that? The reader can only go by how
things are documented. If those are not entirely consistent
with the intend of the programmer, that is not the readers
fault.

just because the Python calling machinery currently happens to allow
that. And chances are that he did *not* expect to be stuck with those
argument names for the foreseeable future, just because someone else
decided to interpret things in the most literal way they possibly could.

And how it the reader of the documentation to know about the
expectations of the programmer? It isn't the readers fault
if those expectations aren't easily inferred from the documenation.

Python 2.X doesn't provide convenient support for distinguishing between
accidental and intentional argument names when you implement a function;
that's a wart, not a feature, and it may be addressed in 3.X.

Again that is not the fault of those that read the documentation. If
this discinction can't be easily made in python 2.X, you can't fault
the reader for coming to a conclusion that seems to follow rather
naturally from how python currently works.

 

[Steven D'Aprano]

on the other hand, if a Python programmer *writes* some code instead;
say, a trivial function like:

def calculate(a, b):
# approximate; gonna have to fix this later
return a + b * 1.2

chances are that he did *not* intend this to be called as

calculate(a=1, b=2)

Developers enable lots of things that they didn't intend. For example,
that function works perfectly well with complex numbers, regardless of
whether or not the developer who wrote it even knows that complex numbers
exist.

We've recently had rather vigorous argument on this list about an alleged
bug in cgi.escape, and the consensus was that it wasn't a bug, but *even
if it were* it couldn't be changed without making a backwards-incompatible
change, and therefore it wouldn't be changed.

For the developer to change the names of a and b in the above published
code would be a backwards-incompatible change.

Under the currently existing Python (rather than some future, hypothetical
Python, or some Python in an alternative reality) all Python arguments are
keyword arguments, whether the developer intends it or not. (Functions
written in C are different.)

At the very least, since names a and b are now part of his code's
published interface, he is responsible for documenting that they are
subject to change. The argument that we should assume that argument names
are subject to change unless told otherwise gets it backwards -- argument
names are part of the published interface to the code, just like the
function name, and therefore should NOT change without warning, if at all.

Now, since so many programmers seem to ignore best-practices, common
practices and even common sense, perhaps Fredrik's heuristic "don't assume
keyword args are keyword args unless explicitly told" might be good,
defensive programming -- a little like "just because the published
interface says the function returns an integer, don't assume it returns an
integer without checking" might be good, defensive practice too.

or, for that matter,

calculate(b=2, a=1)

or

calculate(1, b=2)

just because the Python calling machinery currently happens to allow
that. And chances are that he did *not* expect to be stuck with those
argument names for the foreseeable future, just because someone else
decided to interpret things in the most literal way they possibly could.

There is a convention for marking names as "touch at your own risk". That
convention isn't "everything is touch at your own risk unless told
otherwise". The convention is to use names with a leading underscore.

 

[hanumizzle]

Again that is not the fault of those that read the documentation. If
this discinction can't be easily made in python 2.X, you can't fault
the reader for coming to a conclusion that seems to follow rather
naturally from how python currently works.

It would depend on prior experience with programming (and perhaps mathematics).

-- Theerasak

 

[Magnus Lycka]

Well maybe he didn't intend that, but how is the reader of the
documentation to know that? The reader can only go by how
things are documented. If those are not entirely consistent
with the intend of the programmer, that is not the readers
fault.

I don't think I ever assumed that it was right to call functions
with keyword arguments if they weren't defined with keyword
parameters, but when I read 4.7.2 of the tutorial, I can see that
it's stated through an example that this is a correct thing to do.
I suppose the tutorial (and maybe the language reference) should
be corrected if this isn't supposed to be guaranteed behavior.

It seems like a bad idea to have different calling semantics
depending on whether a callable is implemented in C or Python.
Even if non-keyword parameters in Python implemented callables,
*can* be called with keyword arguments, it seems like a bad
idea to encourage that use. Perhaps it would be a good idea
to deprecate that possibility and remove it in Python 3.0?

I think it's better to force some calls into using f(*a, **kw)
instead of f(**kw) if it decreases the risk that reimplementing
functions in C in an API will break client code. Sure, it's
simple to make a Python wrapper, but if you're after raw speed,
you might not want to do that.

The main downside to removing the possibility of calling non
keyword parameters with keyword arguments might be that using
keyword arguments could fill a documentation purpose in the
code, e.g. x=get(host=arg[0], port=arg[1], path=arg[2]) would
be clearer than x=get(arg[0], arg[1], arg[2]). Of course,
host, port, path = arg; x=get(host, port, path) is even better
(if s/;/\n) but in some cases, it's better to be able to
inline things.

 

[Antoon Pardon]

I don't think I ever assumed that it was right to call functions
with keyword arguments if they weren't defined with keyword
parameters,

I'm not sure I follow here. AFAICS, you can't define keyword
parameters. You can give default values to parameters but
this is orthogonal to calling a function with keywords.

If we somehow want to seperate parameters in those that
can be used with a keyword and those that don't it has
to be something different than providing a default value
to that parameter.

 

[Steve Holden]

I'm not sure I follow here. AFAICS, you can't define keyword
parameters. You can give default values to parameters but
this is orthogonal to calling a function with keywords.

Yup, that's a point that the documentation doesn't make stringly enough.

If we somehow want to seperate parameters in those that
can be used with a keyword and those that don't it has
to be something different than providing a default value
to that parameter.

Indeed.

regards
Steve

 

[Hendrik van Rooyen]

If we somehow want to seperate parameters in those that
can be used with a keyword and those that don't it has
to be something different than providing a default value
to that parameter.

This makes sense - before reading this thread I was under the impression that
giving a variable a default value makes it a keyword variable....

- Hendrik