Are multiple return values really harmful? (Re: determining the number of output arguments)

[Carlos Ribeiro]

On Fri, 19 Nov 2004 10:58:17 +0100, Alex Martelli <aleaxit at yahoo.com> wrote:
> Bengt Richter <bokr at oz.net> wrote:
> 
> > >? No they're not -- a caller knows them, in order to be able to call
> > >with named argument syntax.
> > >
> > I guess you mean keyword arguments, so yes,
> 
> I hate to call them 'keyword' arguments when they aren't (check with the
> keyword module: it will confirm they aren't keywords!-).
> 
> > but for other args I would argue that the caller's
> > knowledge of formal parameter names really only serves mnemonic purposes.
> 
> How does that differ from returning a tuple-with-names?

There is a small difference. In some instances, it's *necessary* to
know the name of the argument; for example, if you want to provide a
partial argument list (the only plausible option involves knowing the
default values of the ommited arguments so you can provide all
arguments as positional ones, but that's ends up being about the same
as far as coupling is concerned).

On the other hand, when a named tuple is used to return a value the
caller isn't required to know the name of the argument. He can
*always* refer to it positionally. (the difference is in the fact that
there are no default values in the "return signature", if we may talk
about such beast).

> > I.e., once the calling code is written, e.g. an obfuscated-symbols
> > version of the function may be substituted with no change in program
> > behavior. So in that sense, there is no coupling: the writer of the
> 
> If the caller doesn't use argument names, you can change argument names
> without breaking the caller.
> 
> If the caller doesn't use field names in a returned tuple-with-names,
> you can change the field names without breaking the caller.
> 
> I don't see any difference.
> 
> > calling code is not forced to use any of the function's internal names
> 
> Same for a tuple-with-names being returned.
> 
> > in _his_ source code. This is in contrast with e.g. a returned dict or
> > name-enhanced tuple: he _is_ forced to use the given actual names in _his_
> > code, much like keyword arguments again.
> 
> Dicts are another issue.  As for tuples-with-names, no way:
> 
>     a, b, c, d, e, f, g, h, i = time.localtime()
> 
> this works, of course, and the caller doesn't have to know which field
> is named tm_day and which one tm_hour or whatever else, unless the
> caller WANTS to use such names for mnemonic purposes.
> 
> The situation is as strictly parallel to passing functions to ordinary
> Python functions as two issues can ever be in programming: foo(a, b, c)
> works but so does foo(bar=b, baz=a, fee=c) if that's the calling style
> the caller prefers for mnemonic/clarity/style reasons.

As I pointed out above, it's not *strictly* parallel. However, I
concede that knowledge about the positional parameters also introduces
a great deal of coupling, more than I assumed at first.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com