Friday Finking: Limiting parameters

[Peter J. Holzer]

On 2020-07-12 08:56:47 +1200, DL Neil via Python-list wrote:
> On 12/07/20 8:13 AM, Peter J. Holzer wrote:
> > On 2020-07-11 09:54:33 +1200, dn via Python-list wrote:
> > > Questions:
> > > 
> > > Is the idea of limiting the number of parameters passed across an interface
> > > a real concern or somewhat an affectation?
> > > 
> > > Is three, five, seven, ... a valid limit (or warning-signal)?
> > > 
> > > Do you have a personal or corporate style or 'standard' to limit parameter
> > > lists to seven parameters, or some other number?
> > > 
> > > Given that Python enables labeled arguments ("keyword arguments"), does the
> > > concern really only apply to 'us' in terms of numbers of "positional
> > > arguments"?
> > 
> > Keyword arguments greatly ameliorate the problems I have with long
> > parameter lists. While I think that calling a function with 7 positional
> > parameters is pretty much unreadable, with 7 named parameters (or maybe
> > 2 positional and 5 named parameters) it doesn't bother me much. The
> > definition of the function might have even more parameters, as long as
> > most of them are optional and have sensible defaults (subprocess.Popen
> > with 20 parameters (if I counted correctly) is pushing it, though).
> 
> Do you think, then, that the maxima should be applied to the number of
> arguments that will appear in the 'expected usage' of the routine? (cf the
> def's parameter-list) After all, calling Popen would rarely require all-20
> arguments be stated, given the acceptability of the defaults and the
> irrelevance of many 'special cases'.

Yes, pretty much. For typical usage, only a few parameters are needed,
and therefore those are the only ones a programmer has to remember. For
the others ... 
When reading code which uses an unfamiliar named parameter, looking it
up is straightforward, so no big deal.
When writing code, the programmer has to remember (or at least suspect)
that the function can do something to be able to look it up - so with a
large number of parameters there is a certain risk that the doesn't even
think of checking the docs. So a function with a large number of rarely
used parameters is still harder to use correctly than one with fewer
parameters, but not much.


> Alternately/additionally, do you feel that the power and readability of
> Python's keyword-arguments + default-values, requires a modification of the
> advice to only limit the number of positional-arguments?

Depends on the advice :-). But yes, I think the advice for a language
which supports named parameters should be different than than for a
language which doesn't. 


> Another discussion-point (which may be difficult because 'the answer' may
> vary according to implementation-requirements): rather than one do-it-all
> 'Swiss Army Knife' of a routine with dozens of parameters, might it be
> better-practice to code a number of methods/functions to take care of the
> special-cases, with a single 'core function' to carry-out the basic
> operations-required? (in a class environment: sub-classes maybe)

I think this depends a lot on the situation. If you have clearly
distinguished scenarios where you would have to use a specific set of
parameters, a set of functions (or methods, or subclasses) may help to
provide "the obvious way to do it". If that's not so clear or if that
would prevent some (legitimate) use-cases, the swiss army knife is
probably better.

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp at hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20200721/7f82236c/attachment.sig>