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

[Carlos Ribeiro]

On Wed, 17 Nov 2004 16:49:03 +1300, Greg Ewing
<greg at cosc.canterbury.ac.nz> wrote:
> Maybe things would be better if we had "dict unpacking":
> 
>    a, c, b = {'a': 1, 'b': 2, 'c': 3}
> 
> would give a == 1, c == 3, b == 2. Then we could
> accept outputs by keyword as well as inputs...

Dicts are not the best way to make it, because they are not ordered
:-) But perhaps we could have something like "named tuples"; immutable
objects, like tuples, with the property that a unique name can be
associated to every item.  Couple it with a decorator, and it can be
written like this:

@returns('year','month','day')
def today():
    ...
    return year, month, day

The return of this function would be a 'named tuple'. It could be
treated like a sequence (using __getitem__), or like a dict (using
__getattr__). This way, we could have the best of both worlds; the
simplicity of tuples and the convenience of named attribute access.

(warning: now I am going to give myself enough rope to hang everyday
in my life... and please, flames off :-)

What if 'named tuples' were supported natively? Entering into pre-PEP
mode (a really dangerous thing to do), the idea is that a sequence
could have a __names__ property, that would contain a tuple of names.
On __set__, this property would automatically build a hash using the
names & and the tuple contents. On __get__, it would simply return a
tuple. (I think that it is better to expose the __names__ attribute as
a tuple, and not as a dict; it's clean, more tuple-like, and hides a
lot of the complexity).

(BTW, I still think that using tuples is convenient, flexible, and as
loosely coupled as it can get. But having named access is also
convenient sometimes).

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com