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

[Alex Martelli]

Bengt Richter <bokr at oz.net> wrote:
   ...
> >Jeremy Bowers wrote:
> >> Generally, returning a tuple is either a sign that your return value
> >> should be wrapped up in a class, or the function is doing too much.
> >
> ISTM that a tuple _is_ a class that wraps content for return as a _single
> value_, just like a custom container class instance. What's the problem?
> The fact that you

None that I can see, no matter how many times Jeremy repeats
"generally".

> is very nice, if you ask me. There are lots of uses for
> small ordered sets of values where no explicit naming
> is required, any more than it is in a call to def foo(r,g,b): ...

Yes, I agree.

> IWT it would be acceptable to limit binding to existing bindings, so that
> frame structure would not have to be altered.

Looks right to me.

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

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


Alex