Friday Finking: Limiting parameters

[DL Neil]

On 12/07/20 9:46 AM, Christman, Roger Graydon wrote:
> I'll preface this by saying I am a programming instructor
> who still teaches from the ivory tower, so may not necessarily
> reflect actual practice in industry.

...in which case I will preface my response by saying that one of the 
virtues of this Discussion List is that we enjoy a wide range of 
membership. It is not limited or even focussed on 'professionals, so 
'ivory tower' members have no less to offer. Similarly, insight from 
ardent hobbyists who (effectively) pay to use Python!


PS there is a Python-Tutor list catering to both trainers and trainees 
which may be of interest and/or a resource for your students. Details at 
https://mail.python.org/mailman/listinfo


Thank you for your considered response!


> But I have a very simple rule of thumb for limiting parameters:
> One should be able to summarize what a function does in one or two
> sentences,  e.g. computes the volume of a cone, or print address labels.
> To fully understand the details of the task would certainly involve
> listing the parameters, but I would generally expect that a practical
> function would naturally put a cap on how much data is provided.
> If you need to include more than 7 parameters to describe what
> it is you want to do, you are probably doing more than one thing,
> or doing something unnecessarily complicated.

+1
(see also @Peter's example of ~20 parameters, and in PSL code, no less!)


> I'll take your example with the address, and assume I want to
> print a mailing label.    I could certainly see you needing to print:
> first name, middle initial, last name, house number, street name,
> apartment number, town, state, country, zip code, (and maybe more),
> and listing all of those individually would produce a very long list.
> 
> But these values really are not all that independent of each other.
> A person's name can be viewed as a single value that happens to
> have multiple parts (collect that into a tuple or class).   Similarly,
> a street address is a single object with multiple parts.   These can
> easily be delivered as complete objects for a short parameter list.

A good summary.

Is there a counter-argument, that because the tuple or class is an 
encapsulation, its contents have to be taken on-trust - the component 
list is not as explicit as: street, number, town, city. Are we a 
particularly 'trusting' bunch? (particularly those who have been 
'bitten' by assumptions in the past...)


> That does not necessarily mean that the function needs to know
> the particular representation or form of that data.   Let those be
> objects with getter methods for the data you wish, and have the
> function document what methods it will attempt to call.   Then
> any class that provides the expected methods would be suitable.

+1

Here, the proposal is not to pass an object per-se, but to pass a 
function/method ("getter method") which will deliver the requisite 
data-items?

So, might we then find that our mailing-label routine includes something 
like (copy-pasting is NOT proper Python!):

def mail_label( getter ):
     ...
     ( first name, middle initial, last name, house number, street name,
     apartment number, town, state, country, zip code ) = getter()

In which case, have we not moved the "very long list" from the function 
def to a later line within the routine - and how is this in some way 
'better'?


> That would also greatly simplify some other features for the problem.
> For example, "first name" "last name" really does not mean the same
> thing as "individual name" "family name", when some countries
> list the family name first.   So it might be better to have a name
> object include a "full name" method for the print-mailing-address
> function to call instead of giving it access to component parts.

+1
As mentioned, keep all the 'stuff' related to person/address in one 
place, rather than expecting mail_label() to know the attributes of the 
class! ('stuff' meaning the data-access methods as well as the 
data-attributes themselves)


> TL;DR:  I expect each parameter to a function to be independent
> or orthogonal to the others.   Values that are closely related to
> each other can probably be encapsulated into a collection or object.
> If you still end up with a large number of independent parameters,
> I would question the simplicity of your function's intent.

Well said! Zen of Python (includes):
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
-- 
Regards =dn