Can Python function return multiple data?

[Rustom Mody]

On Friday, June 5, 2015 at 3:46:47 AM UTC+5:30, Steven D'Aprano wrote:
> On Fri, 5 Jun 2015 03:26 am, random832 wrote:
> > If the value really were 23, the "is vs ==" problem wouldn't exist.
> 
> What "problem"? "is versus ==" is not a problem, it is a feature. The two
> operators do two different things.
> 
> But I am *astonished* that you think that the value of x after x = 23 is not
> 23. If it's not 23, then what is it?
> 
> (Actually, I'm not that astonished. There are some kinds of foolishness that
> only really smart people can fall for.)

Yeah some rather smart people... 

http://en.wikipedia.org/wiki/BLISS#Language_description
[See the part on 'reference to a variable']
In C in
x = y
x is l-value y is r-value and the choice of which attribute to select is
context-sensitive.
In this regimen it is uniform and straightforward, variable only ever
means l-value. r-value is obtained with a dot-operator '.x'
So the usual C's
x = y
in Bliss is 
x = .y

[BTW the lead to the wikipedia article describes Bliss as the best known
system programming language till C made its debut]

Also I believe Algol-68 similarly uniformed variable refs but in the opposite
direction [if I understand it right]
C's
x = y
becomes in Algol-68
ref x := y
[Admittedly the Algol-68 docs are too dense for me so I may be misunderstanding]

In any case my points

1. C's context sensitive variables is quite strange.
Even if (in 2015) its the universally acceptped norm there were more
intelligent/intelligible times...

2. If you think is vs == is not a problem, you are not paying attention to the
repeated arguments/confusions around that subject

[The cognoscenti argue, the ignoramuses are confused. Its probably the other
way round -- the ignorants' displayed confusion probably indicates the cognoscenti's real confusion

3. Functional programming choice to throw the baby out with the bathwater
-- no assignment, no mutation -- is extreme but not unfounded