approach to writing functions

[Peter Hansen]

Joe Mason wrote:
> 
> Hee hee.  As the guy who disagreed with Terry before on philosophy, I'm
> going to agree with him now on practicals.  

Actually all three of us are agreeing on practicals then, because I 
wouldn't actually suggest anyone waste time chopping a little utility
like that up into many functions after it has already been written
and is working.

> There's no reason to split
> up this code into three or four functions.  

Agreed.  On the other hand, there's *excellent* reasons to write it 
as three or four functions in the first place, especially if one is
trying to learn how to write well crafted code.  You can't learn how
best to make use of "functions" (or any other software construct) by
just listening to others spout off about it... you gotta try it out 
yourself (advice to the OP).

If you can't see the distinction, I'll make myself clearer in a subsequent
message. :-)

> (If I were writing it for the first time, I might use
> that loop comprehension depending on how many commands there are.  It's
> a very useful shortcut if you're doing the same thing a lot, but it's
> one more layer of comprehension you have to look past to see what the
> code is doing.)

I dislike having many data-specific variables (e.g. "user", "password",
"address", "port", etc) kicking around if they are there only to hold 
data for a line or two but won't be used more than once.

In other words, if you have four things to retrieve, and will immediately
pass them on to a function (or in this case a string formatting operator)
that will use them in the same order, the simplest thing is just to 
assign them as a tuple never handle them individually.  That's why I
tended towards the list-comprehension approach above.

Chances are my own code wouldn't have ended up with that particular line
in that particular place, so I doubt in my own version of this I would
actually have had the same list comprehension.

-Peter