Re: Friday Finking: Limiting parameters

[dn via Python-list]

On 22/07/2020 05:37, Peter J. Holzer wrote:

On 2020-07-13 17:21:40 +1200, dn via Python-list wrote:

On 12/07/20 10:10 PM, Barry Scott wrote:

I'd expect to see something like this:

def mail_label( person, address ):
first_name = person.first_name
# or if you want a function interface
first_line_of_address = address.get_first_line()


Does this idea move whole objects across the interface? (see earlier in the
thread)


Assigning an object in Python only copies a pointer (and may adjust some
house-keeping info, like a reference count). So it doesn't matter
whether the object  has 5 fields or 50. The function will only access
those it knows about and ignore the rest.


Yes, poor choice of words in "move". Perhaps (he says rather weakly), 
think in terms of move-ing control - from the object to the function. Is 
this the best idea?


The point being that the function needs to 'know things' about the 
object, ie 'I want to make the identification line of the address so I 
must retrieve title, first-initial, family-name, ... all names which 
exist inside the object. In our example, the example-object has been 
person, so it's not big deal. What happens if in-future we develop a 
mailing-list for companies? The mail-label function now appears to be 
requiring that the company object use exactly the same attribute-names 
as person!


The obvious alternative might be to pass all three data-values (in the 
example). Now the function only needs to know what it intends to call 
the three parameters - nothing more. However, our argument-count 
increases again...


Another alternative would be to pass a method which will retrieve those 
fields from the object, delivering them in the form[at] expected by the 
function. In this case, the object provides the interface and the 
mail-label routine can get-on with what it knows best, without needing 
to know the who/what/where/how of data held by 'whatever is out-there'. 
(also, counts as only one argument!)




One might argue that mail_label should be a method of the person object
because it depends on the person (e.g., depending on the ethnicity of
the person the name might be written "first_name last_name" or
"last_name firstname"). OTOH a person may have many addresses (and an
address shared by many people), so a function which combines a person
and address (which therefore can't be a method of either person or
address) may be better.

Maybe that should be treated as a model-view relationship: You have two
models (person and address) and a view (which combines some aspects of
both while ignoring others).


So, would this be merely "has-a" composition, or is it where other 
languages would use "interfaces"? (and if-so, what is the pythonic 
solution?)

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Limiting parameters

[Peter J. Holzer]

On 2020-07-13 17:21:40 +1200, dn via Python-list wrote:
> On 12/07/20 10:10 PM, Barry Scott wrote:
> > I'd expect to see something like this:
> > 
> > def mail_label( person, address ):
> > first_name = person.first_name
> > # or if you want a function interface
> > first_line_of_address = address.get_first_line()
> 
> Does this idea move whole objects across the interface? (see earlier in the
> thread)

Assigning an object in Python only copies a pointer (and may adjust some
house-keeping info, like a reference count). So it doesn't matter
whether the object  has 5 fields or 50. The function will only access
those it knows about and ignore the rest.

One might argue that mail_label should be a method of the person object
because it depends on the person (e.g., depending on the ethnicity of
the person the name might be written "first_name last_name" or
"last_name firstname"). OTOH a person may have many addresses (and an
address shared by many people), so a function which combines a person
and address (which therefore can't be a method of either person or
address) may be better. 

Maybe that should be treated as a model-view relationship: You have two
models (person and address) and a view (which combines some aspects of
both while ignoring others).

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 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.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Limiting parameters

[Barry Scott]

> On 13 Jul 2020, at 06:21, dn via Python-list  wrote:
> 
> On 12/07/20 10:10 PM, Barry Scott wrote:
>>> On 12 Jul 2020, at 00:15, DL Neil via Python-list >> > wrote:
>>> 
 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'?
>>> 
>> This is not the refactor that Roger's excellent rule-of-thumb implies.
>> Clearly moving the 20 positional args into a tuple is basically the same 
>> code,
>> and the same maintenance problem.
> 
> Agreed!
> 
> 
>> I'd expect to see something like this:
>> def mail_label( person, address ):
>> first_name = person.first_name
>> # or if you want a function interface
>> first_line_of_address = address.get_first_line()
> 
> Does this idea move whole objects across the interface? (see earlier in the 
> thread) Taking a person class as subject and a mailing-label as the 
> function's object, aren't there two criticisms?
> 
> 1 the function needs to know which attributes of the person and address 
> objects it wants to use, cf saying 'I need street, number, town, ...'*

That is part of the requirements spec for the function - the function author 
will implement against spec so will know what is needed.

> 
> 2 "person" likely contains a load of data that is irrelevant to printing a 
> mail-label.

The design problem we are solving is that it is easy (more maintainable) to 
call the function with a small number of args that provide what is needed.
Having access to more than the minimum information is not a problem usually.

One function might only need the family-name, another function the given-name 
(choose terms that match your region and culture here).

> 
> Why is this preferable to using a 'getter' method, or some other approach?

The idea of getter methods is to hide the implementation details of an object 
that may compute a value.
This is useful when refactoring and debugging, but can be over complex for a 
simple app/object.

person.get_name_formal() vs. person.get_name_informal() could use the same
set of data combined in different ways.

> 
> * your point (above) being that these need not be (say) a dozen data 
> elements, but could be just-enough data, and data-combinations which identify 
> the addressee and which represent the components of the address.

The app designer will have to design the API to person and address that makes 
sense in the app.

Barry

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Limiting parameters

[dn via Python-list]

On 12/07/20 10:10 PM, Barry Scott wrote:
On 12 Jul 2020, at 00:15, DL Neil via Python-list 
mailto:python-list@python.org>> wrote:



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




This is not the refactor that Roger's excellent rule-of-thumb implies.

Clearly moving the 20 positional args into a tuple is basically the same 
code,

and the same maintenance problem.


Agreed!



I'd expect to see something like this:

def mail_label( person, address ):
first_name = person.first_name
# or if you want a function interface
first_line_of_address = address.get_first_line()


Does this idea move whole objects across the interface? (see earlier in 
the thread) Taking a person class as subject and a mailing-label as the 
function's object, aren't there two criticisms?


1 the function needs to know which attributes of the person and address 
objects it wants to use, cf saying 'I need street, number, town, ...'*


2 "person" likely contains a load of data that is irrelevant to printing 
a mail-label.


Why is this preferable to using a 'getter' method, or some other approach?

* your point (above) being that these need not be (say) a dozen data 
elements, but could be just-enough data, and data-combinations which 
identify the addressee and which represent the components of the address.

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Limiting parameters

[Barry Scott]

> On 12 Jul 2020, at 00:15, DL Neil via Python-list  
> wrote:
> 
>> 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'?
> 

This is not the refactor that Roger's excellent rule-of-thumb implies.

Clearly moving the 20 positional args into a tuple is basically the same code,
and the same maintenance problem.

I'd expect to see something like this:

def mail_label( person, address ):
first_name = person.first_name
# or if you want a function interface
first_line_of_address = address.get_first_line()

Barry

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Limiting parameters

[DL Neil via Python-list]

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
--
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Limiting parameters

[Christman, Roger Graydon]

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.

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.

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.

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.

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.

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.

Roger Christman
Pennsylvania State University
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Limiting parameters

[DL Neil via Python-list]

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
--
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Limiting parameters

[Peter J. Holzer]

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


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

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Friday Finking: Limiting parameters

[dn via Python-list]

Do you prefer to limit the number of parameters accepted by a single 
function/method, and if so, how do you handle situations where more data 
is needed?


TLDR; specific questions at the end of this msg


Along with one of our list-colleagues (a fellow graduate?survivor from 
the time of mainframe computers, monolithic programs, when "structured 
programming" was 'the latest new idea', and OOP[s] was one's exclamation 
upon making a mistake) we have been re-reading and discussing "Code 
Complete". It is 'an oldie, but a goodie', and Python progs may feel 
so-superior by happily looking-past various C*/Java-based ideas.


The chapter on "High-Quality Routines" covers a lot of (hopefully, to 
you) familiar ground, eg structural-decomposition, descriptive names, 
manageability, readability, reliability, changeability, isolating 
complexity, SRP, strong-cohesion, loose-coupling (and all the fun of the 
fair...).


A particular focus is "Parameter passing issues" - that the list as an 
whole presents a "consistent interface abstraction", that the parameters 
are in a sensible sequence (that it matches any other similar function 
signatures), and that assumptions are documented. The recommendation is 
that the list be <= seven parameters. [I have a recollection that 
someone else (?'Uncle Bob Martin') recommends <= three]


What should one do when a routine requires numbers of input values? Does 
Python's lack of "interfaces" let us down?



If we were going to be pedantic, then the quick-and-dirty way to reduce 
the parameter-count might be to use a collection, eg put a physical 
address into a named-tuple or list called "address" instead of passing 
"street", "town", "city", "postal_code", etc.


We shouldn't be childish when it comes to style-guides. If the data is 
as cohesive as the components of an address, we should define a class. 
Now we can pass a single instantiated-object, with style and flair!


However, the criticism of that idea is that it 'breaks' encapsulation - 
the parameter's routine now needs to know which data-attributes exist 
within the passed object - which is an example of close-coupling. Also, 
if instead of creating a new object, eg "address", we passed across a 
containing object, eg "person"; we might save ourselves some effort! 
Sadly, we would (likely) be passing loads of unnecessary data, possibly 
even in an insecure fashion.


Time for some compromise? How about we add a method to the "address" 
example-object, which is then passed to the routine? It can be called, 
and deliver the object's necessary attributes per the interface's spec. 
NB we can do this in Python because a function/method is a "first-class 
object"! Now our parameter list is shortened (hopefully to the 
recommended degree) - thus also the degree of "coupling" between the 
call-ing and call-ed routines, the data passed is minimised, and the 
communication across the interface clarified. That said, haven't we now 
built what other languages might call an "interface"?



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"?


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? After all, we could 
just as easily build an extraction-routine into the calling-class, which 
reaches into the passed-class for the data it needs - then we don't have 
to go to the other team to ask their 'permission'/agreement/cooperation 
or wait for them to build the requisite method!


Is passing a function as an argument a safe and valid way to do 
business, or is it 'showing off'?


Does the pass-a-function idea making testing easier (of both the call-ed 
and the call-ing routines) and might it make a change (eg adding another 
field) easier to manage in-future?


What do you do?


Refs:
Steve McConnell, "Code Complete", Microsoft Press, 2004.
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list