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

[Alex Martelli]

Bengt Richter <bokr at oz.net> wrote:
   ...
> >I hate to call them 'keyword' arguments when they aren't (check with the
> >keyword module: it will confirm they aren't keywords!-).
   ...
>  TypeError: foo() got an unexpected keyword argument 'z'

Yeah, it's official python terminology, just hateful.

> OTOH, I have been arguing from an untested assumption *<8^P. I didn't
> realize that 'keyword' style named parameter passing could be used
> with the ordinary named parameters!

Ah, OK, couldn't realize that misapprehension on your part.

> >> but for other args I would argue that the caller's
> >> knowledge of formal parameter names really only serves mnemonic purposes.
> >
> >How does that differ from returning a tuple-with-names?
> I guess you are referring to those names' also being for optional use,
> i.e., that you can unpack a tuple-with-names the old fashioned way if you
> want. Hm...

Yes, I took that for granted.

> but that might lead to ambiguities if we are to have automatic name-driven
> unpacking. I.e.,
> 
>     c,a,b = tuple_with_names
> 
> might be different from
> 
>     c,a,b = tuple(tuple_with_names)

It had better not be, otherwise the tuples-with-names returned by
standard library modules such as time, os, resource, would behave
differently from these new tuple_with_names.  IOW, we don't want
name-driven unpacking from these tuples with names -- at least, I most
assuredly don't.  Are these tuple_with_names not iterables?!  Then they
must be unpackable this way like ANY other iterable:

>>> a, b, c = dict(a=23, b=45, c=33)
>>> print a, b, c
a c b

If you're talking about backwards incompatible changes (Python 3000) it
might be good to separate the thread from one which I was participating
in because of potential interest for Python 2.5.  As long as we're not
considering backwards incompatible changes, it's unthinkable to have
iterables that can't be unpacked, even though the results might not be
what you might expect.


> method? Maybe we need to have an explict operator for name-driven
unpacking, e.g.,

Probably some kind of distinguished syntax, though a new
assignment-operator seems way overkill for the tiny benefit.



Alex