[Python-ideas] values in vs. values out

[Nick Coghlan]

On Tue, Jan 18, 2011 at 1:04 AM, Luc Goossens <luc.goossens at cern.ch> wrote:
>> If the system automatically ignored "new" return values (for whatever
>> "new" might mean), I think it would be too easy to miss return values that
>> you don't mean to be ignoring.
>
> this I guess is only valid in the case where multiple return values are so
> strongly related they probably should be an object instead of a bunch of
> values

If the relationship between the return values is so weak, I would
seriously question the viability of returning them at all.

>> So it would be neat if you could do:
>>
>> (a, b, c=3) = func(...)
>
> or adding keywords to the mix
>
> a, b, c = kw1, d = kw2 (defval2)   =   function(...)
>
>
> now for the can of worms ...
>
> - one would need some syntactic means to distinguish the returning of two
> values from the returning of a single pair with two values
> - there's a complication with nested function calls (i.e. fun1 ( fun2(...),
> fun3(...)); the only simple semantic I could associate with
> this, is to simply drop all return values except for the first, but that is
> incompatible with returning the full return value of a function without
> needing to manipulate it
> ...
>
> Hmm, maybe the second worm above hints at the root problem with multiple
> return values: there is just no simple way of accommodating them.

If you want additional independent return values, use a container
(such as a list or dictionary) as an output variable.

Even better, if you want to change the return value without having to
change every location that calls the function, *create a new function*
instead of modifying the existing one. Yes, this means you can
sometimes end up with lousy names for functions because the original
function used up the best one. Such is life in a world where you need
to cope with backwards compatibility issues.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia