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@python.org http://mail.python.org/mailman/listinfo/python-ideas