Are multiple return values really harmful? (Re: determining the number of output arguments)
aleaxit at yahoo.com
Thu Nov 18 08:56:30 CET 2004
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
> 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.
More information about the Python-list