On Thu, Jan 13, 2011 at 8:30 AM, Luc Goossens <luc.goossens@cern.ch> wrote:
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).

As others have mentions, if you return a dictionary or a named tuple from the function will a little more flexiblity with respect to argument order. In the end no matter what is done, there is still going to be a pretty tight semantic coupling between what a function returns and how the caller accesses it, so there are limits to what you can achieve with syntax.

I would like to note that the complexity of passing arguments into functions is not a pure win. The flexibility has a cost in terms of complexity, learnability, speed, and implementation challenges.

ISTM that very few people fully grok all of the existing capabilities. I don't think that adding yet more complexity to the language would be a net win. As C++ has shown, when you start getting to feature rich, the features will interact in unexpected ways. For example, how would all those options for processing return values interact with augmented assignment?

funcdef: 'def' NAME parameters ['->' test] ':' suite

parameters: '(' [typedargslist] ')'

typedargslist: (tfpdef ['=' test] (',' tfpdef ['=' test])* [','

['*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef]]

| '*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef)

tfpdef: NAME [':' test]

varargslist: (vfpdef ['=' test] (',' vfpdef ['=' test])* [','

['*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef]]

| '*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef)

vfpdef: NAME