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

[Alex Martelli]

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?

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


Alex