107
107
``**kwargs`` in the prototype of a function should be used sparingly.
109
108
It can be good on higher-order functions that decorate other functions,
110
such as ``addCleanup`` or ``assertRaises``. Otherwise, be careful:
109
such as ``addCleanup`` or ``assertRaises``, or on functions that take only
110
(or almost only) kwargs, where any kwargs can be passed.
112
If the parameters to a function are a bit complex and might vary over
113
time (e.g. the commit API) then I think what's really called for is an
114
explicit object for the parameters (e.g. I think we should create a
115
CommitParams object), rather than a bag of positional and/or keyword
116
args. If you have an arbitrary set of keys and values that are
117
different with each use (e.g. string interpolation inputs) then again
118
I think that should not be mixed in with the regular
119
positional/keyword args, it seems like a different category of thing.
112
Otherwise, be careful: if the parameters to a function are a bit complex
113
and might vary over time (e.g. the ``commit`` API) then we prefer to pass an
114
object rather than a bag of positional and/or keyword args. If you have
115
an arbitrary set of keys and values that are different with each use (e.g.
116
string interpolation inputs) then again that should not be mixed in with
117
the regular positional/keyword args, it seems like a different category of
122
121
Imitating standard objects
added
removed
doc/developers/code-style.txt
