determining the number of output arguments

[Josiah Carlson]

Jeremy Bowers <jerf at jerf.org> wrote:
> 
> On Mon, 15 Nov 2004 23:43:55 -0800, Josiah Carlson wrote:
> > Guido hasn't updated his stance, so don't hold your breath.
> 
> I'm not in favor of it either. I just think that *if* it were going in, it
> shouldn't be a "keyword".
> 
> I think variable size tuple returns are a code smell. Now that I think of
> it, *tuple* returns are a code smell. (Remember, "code smells" are strong
> hints of badness, not proof.) Of the easily thousands of functions in
> Python I've written, less than 10 have returned a tuple that was expected
> to be unpacked. 

I agree with you on the one hand (I also think that variable lengthed
tuple returns are smelly), and have generally returned tuples of the
same length whenever possible.  However, I can't agree with you on
general tuple returns. Why? For starters, dict.[iter]items(),
struct.unpack() and various client socket libraries in the standard
library that return both status codes and status messages/data on
command completion (smtplib, nntplib, imaplib).


> 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. One of
> the instances I do have is a tree iterator that on every "next()" returns
> a depth *and* the current node, because the code to track the depth based
> on the results of running the iterator is better kept in the iterator than
> in the many users of that iterator. But I don't like it; I'd rather make
> it a property of the iterator itself or something, but there isn't a
> code-smell-free way to do that, either, as the iterator is properly a
> method of a certain class, and trying to pull it out into its own class
> would entail lots of ugly accessing the inner details of another class. 

The real question is whether /every/ return of more than one item
deserves to have its own non-tuple instance, and whether one really
wants the called function to define names for attributes on that
returned instance. Me, I'm leaning towards no.  Two, three or even
four-tuple returns, to me, seem reasonable, and in the case of struct,
whatever suits the program/programmer.  Anything beyond that should
probably be a class, but I don't think that the Python language should
artificially restrict itself when common sense would keep most people
from:
a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z = range(26)

...or at least I would hope.

 - Josiah