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

Magnus Lycka lycka at carmen.se
Thu Oct 12 05:28:59 EDT 2006


Antoon Pardon wrote:
> 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.



More information about the Python-list mailing list