Can Python function return multiple data?

[Rustom Mody]

On Friday, June 5, 2015 at 8:07:41 AM UTC+5:30, Steven D'Aprano wrote:
> On Fri, 5 Jun 2015 08:59 am, random832 wrote:
> 
> > On Thu, Jun 4, 2015, at 18:16, Steven D'Aprano wrote:
> >> Remember, you've tried to claim that it is not invisible or unknown, so
> >> you
> >> must be able to see and know that value. So what is the value?
> > 
> > It doesn't have to have a string representation to exist. But if you
> > really want one?
> > 
> >>>> object.__repr__(23)
> > '<int object at 0x10024af00>'
> 
> That's not a reference to the value. That's a string that describes the
> object. If it returned
> 
> "twenty-three"
> 
> would you claim that the string "twenty three" is the value of x?
> 
> I think there is a simple, obvious, common-sense answer here:
> 
> * given `x = 23`, the value of x is 23;
> 
> * given `x = [1, 2]`, the value of x is the given list [1, 2];
> 
> * given `x = "Hello World", the value of x is the string "Hello World";
> 
> * given `x = object()`, the value of x is the given instance of type object.
> 
> That's so simple and obviously correct. Compare to:
> 
> * given `x = 23`, the value of x is not actually 23, but some invisible
> reference to 23;
> 
> * given `x = [1, 2]`, the value of x is not actually [1, 2], but some
> invisible reference to [1, 2]; 
> 
> etc. I'm sure you can extrapolate to the other examples.
> 
> The *only* reason for making this claim is to rationalise the belief that
> passing x to a function is pass by value. Since the list [1, 2] is
> obviously not copied, it becomes necessary to find something, anything,
> which *is* copied, and identify that as "the value of x". Is there any
> other context where you would want to say that the value of x isn't [1, 2]?
> 

Sounds simple...
Until you realize that what the *is* is emphasizing [your emphasis] is not all
that clear.

Consider the C canonical linked-list example (of some type T):

struct node
{
   T elem;
   struct node *next;
};

Is the list in C to be identified with 'struct node'?

If you will see the usage pattern you would find that in most cases the
usage is for some p of type struct node*
To make it more explicit there are TWO mutually recursive types:

typedef struct node *nodeptr;
struct node
{
  T elem;
  nodeptr next;
}; 

And now if we ask which of node and nodeptr should we identify with the
list type, the answer is not quite clear.
- In all cases of usage we would find we need to use nodeptr
- Except for  "newp = (nodeptr)malloc(sizeof(struct node))"
- However nodeptr has no meaning other than referring (pointing) to 
   something... What?

My conclusion: C does not support lists at all in a first class way.
The C programmer needs to visualize/imagine them in the nebulous gap between
node and nodeptr.

The same situation obtains here in python:

The abstract platonic immutable list is non-existent in python
Use no mutation and the pretence that the list [1,2] *is* the list [1,2] works.

Start using mutation and the ground starts wobbling.
The only way to stay steady (that I know) in this wobbly world is to hold to
two concepts:
1. The abstract platonic immutable type -- good to think with, supported by 
python in only a half-assed way

2. The 'maybe-reference-maybe-value' actual mess

And to keep dancing between these