determining the number of output arguments

[Jeremy Bowers]

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. 

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.