[Python-ideas] values in vs. values out

[Luc Goossens]

Hi all,

Thanks to everybody for your feedback!
So I guess the answer to my question (which - I noticed just now - did  
not end with a question mark), is ... no.

> If your function is returning a bunch of related values in a tuple,  
> and
> that tuple keeps changing as you re-design the code, that's a code  
> smell.

the use cases I have in mind are the functions that return a set of  
weakly related values, or more importantly report on different aspects
of the calculation;
an example of the first is a divmod function that returns the div and  
the mod while callers might only be interested in the div;
examples of the latter are the time it took to calculate the value,  
possible warnings that were encountered, ...

like the good old errorcode/stdout/stderr trio

> [various workarounds suggested]


the problem with (all) the workarounds that were suggested is that  
they help with migrating from 2 to more return values;
for the 1 to 2 case (the most common case) they don't help a lot, as  
the amount of work to put the workaround in place exceeds the amount  
of work to cope
with the migration directly;
I would say it is a requirement that the simple case of single  
variable gets single (or first) return value, retains its current  
simple notation


> 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


> 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.

Too bad :-(
Luc




On Jan 13, 2011, at 3:30 PM, Luc Goossens wrote:

> Hi all,
>
> There's a striking asymmetry between the wonderful flexibility in  
> passing values into functions (positional args, keyword args,  
> default values, *args, **kwargs, ...) and the limited options for  
> processing the return values (assignment).
> Hence, whenever I upgrade a function with a new keyword arg and a  
> default value, I do not have to change any of the existing calls,  
> whereas whenever I add a new element to its output tuple, I find  
> myself chasing all existing code to upgrade the corresponding  
> assignments with an additional (unused) variable.
> So I was wondering whether this was ever discussed before (and  
> recorded) inside the Python community.
> (naively what seems to be missing is the ability to use the  
> assignment machinery that binds functions' formal params to the  
> given actual param list also in the context of a return value  
> assignment)
>
> cheers,
> Luc
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas