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

Donn Cave donn at u.washington.edu
Wed Nov 17 15:31:34 EST 2004


In article <mailman.6491.1100708505.5135.python-list at python.org>,
 Dave Brueck <dave at pythonapocrypha.com> wrote:
> Greg Ewing 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.
> > 
> > 
> > While I suspect you may be largely right, I
> > find myself wondering why this should be so. 
> 
> *Is* it largely right? I don't think so. As you said, there doesn't seem to be 
> anything "wrong" with passing multiple pieces of data _into_ a function, so why 
> should we assume that complex data passing should be so one way?

What's up with keyword arguments, then?  I don't think you can argue
that on one hand keyword arguments are a valuable feature, but plain
by-order tuples are a totally satisfactory interface on the other hand.

> One of my biggest pet peeves about programming in C, for example, is that you 
> are often forced to wrap stuff up into a structure just to pass data back and 
> forth - you create the structure, populate it, send it, and then pull out the 
> data.
> 
> In many, many cases this is nothing more than poor-man's tuple unpacking, and 
> you end up with lots of extra work and lots of one-off structures. Also 
> annoying 
> is the use of "out" parameters, which is again basically manual tuple 
> unpacking.

Take stat(), which for those who haven't used it reports a number
of characteristics of a file.  It's not the ideal example, because
it's big (10 items) and it's already "fixed" (has attributes like
a class instance.)  But its worst problem has nothing to do with
the size, or whether or not the items can be referred to by name.
As long as they can be referred to by position, we're stuck with
the exact same items on all platforms, in all situations, for the
rest of eternity.  Whether some of them might not really be supported
on some platforms, or it omits some useful values on others. It's
not very flexible.  C stat(2) doesn't have this problem.

I don't know if I'd go along with "largely right", but it could
fall somewhere between "some truth in it" and "completely whacked."

   Donn Cave, donn at u.washington.edu



More information about the Python-list mailing list