Friday Finking: Limiting parameters

DL Neil PythonList at DancesWithMice.info
Sat Jul 11 16:56:47 EDT 2020


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'.

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?

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)


>> Why not simply create and pass a collection (to suit the 'standards
>> committee') and be done. What's the big deal, don't have time to waste,
>> bureaucracy (!)...
>>
>> What about the similar Q+D solution using a class?
> 
> That's what I often do. The main reason is that often a lot of those
> parameters are repetitive. So instead of passing the same 7 parameters
> to every function, I create a "Context" or "Job" class with those 7
> fields which I then pass to each function. So it not just looks tidier,
> it also reduces the risk of inconsistencies.

+1
Good thinking: promotes (indeed, dictates) consistency of interface!
-- 
Regards =dn


More information about the Python-list mailing list