On Sat, Jan 26, 2019 at 10:43 AM David Mertz <mertz@gnosis.cx> wrote:
No. It's simpler than that! Functions return a single value, period.

That single value might happen to be a tuple or something else unpackable.

d'uh -- I was thinking common use case.
 
This makes it feel like we have multiple return values, but we never actually do. The fact that "tuples are spelled by commas not by parentheses" makes this distinction easy to ignore most of the time.

yup. And  unpacking behavior. So I guess the correct way to phrase that is that functions return a single object, and that object may or may not be unpackable.

Key to this is that unlike function parameters, python isn't doing anything special when returning a value form a function, or when assigning a value to a name:

* functions return a value

* assignment applies unpacking when assigning to multiple names.

These two things are orthogonal in the language.

The challenge in this case is that when you assign to a single name, there is no unpacking:

x = 3,

So in this case,  the 1-tuple doesn't get unpacked  --  when you are assigning to a single name, there is no unpacking to be done.

but you can unpack a one-tuple, by assigning to  name with a trailing comma:

In [62]: x, = (3,)                                                              

In [63]: x                                                                      
Out[63]: 3

So the challenge is that to support this new feature, we'd need to changing assignment, so that:

x = an_object

would look at an_object, and determine if it was one of these function_return_objects that should have the first value unpacked if assigned to a single name, but unpack the others if assigned to a tuple of names -- and THAT is a pretty big change!

And it would still create odd behavior if teh function return value were not assigned right away, but stored in some other container:

a_list = [fun1(), fun2()]

So really, there is no way to create this functionality without major changes to the language.

-CHB


-CHB

--
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython