[Python-ideas] values in vs. values out
luc.goossens at cern.ch
Mon Jan 17 16:04:43 CET 2011
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,
> that tuple keeps changing as you re-design the code, that's a code
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
> 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
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
Too bad :-(
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
> Python-ideas mailing list
> Python-ideas at python.org
More information about the Python-ideas