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

Carlos Ribeiro carribeiro at
Thu Nov 18 13:18:48 CET 2004

On Thu, 18 Nov 2004 08:56:30 +0100, Alex Martelli <aleaxit at> wrote:
> Bengt Richter <bokr at> wrote:
> > Still, as Carlos pointed out, formal parameter names
> > are private to a function,
> ? No they're not -- a caller knows them, in order to be able to call
> with named argument syntax.

On my original post I pointed out that named arguments are an
exception to this rule. For the most of the times, the caller does not
*need* to know the internal argument names. Named arguments are
entirely optional, and in fact, if you provide the arguments in the
correct order, you can avoid using them in almost every situation
(**kw being the exception).

The point was: fixing names on the return code introduces coupling.
But after thinking a little bit more, the issue does not seem as clear
to me as before. After all, *some* coupling is always needed, and
positional return values also are "coupled" to some extent. I think
that the named tuples idea is nice because it works entirely
symmetrical with the named arguments; it allows to use a shortcut
positional notation, or to use a named access, at the will of the
programmer, for the same function call.
> > I.e., if the dict has additional content, it is not an error
> Agreed, by analogy with '%(foo)s %(bar)s' % somedict.
> > Hm, do you want to go for a dict.get-like default value in that?
> No, enriching dicts to support an optional default value (or default
> value factory) looks like a separate fight to me.  As does syntax sugar,
> IMHO.  If we can get the semantics in 2.5 with a PEP, then maybe sugar
> can follow once the usefulness is established to GvR's contents.

I'm also trying to focus on tuples, so I'm leaving dicts out of this
for now. But clearly named tuples & immutable dicts are closely
related; but of the two, named tuples have an advantage because they
are naturally ordered.

Carlos Ribeiro
Consultoria em Projetos
mail: carribeiro at
mail: carribeiro at

More information about the Python-list mailing list