Is this valid ?

[Stef Mientki]

hello,

by accident I typed a double value test,
and to my surprise it seems to work.
Is this valid ?

a = 2
b = 2

a == b == 2

thanks,
Stef Mientki

 

[Mike Driscoll]

hello,

by accident I typed a double value test,
and to my surprise it seems to work.
Is this valid ?

a = 2
b = 2

a == b == 2

thanks,
Stef Mientki

It sure looks that way...

See http://www.python.org/doc/2.3.5/ref/comparisons.html for more
info.

Mike

 

[John Machin]

hello,

by accident I typed a double value test,
and to my surprise it seems to work.
Is this valid ?

a = 2
b = 2

a == b == 2

Of course. You can chain comparisons as much as you like and is
(semi-)sensible, e.g.

assert 0 < thing_index < thing_count <= UTTER_MAX_NTHINGS

There was an interesting use of chained comparison within the last day
or 2 in a thread about deriving a set of duplicated list elements --
look for subject == "finding items that occur more than once in a
list" and author == "Arnaud Delobelle".

Cheers,
John

 

[Lie]

hello,

by accident I typed a double value test,
and to my surprise it seems to work.
Is this valid ?

a = 2
b = 2

a == b == 2

thanks,
Stef Mientki

a == b == 2
is equivalent to
a == b and b == 2
except that b is only evaluated once for the whole comparison

 

[Rolf van de Krol]

Of course. You can chain comparisons as much as you like and is
(semi-)sensible, e.g.

Hmm, 'of course' is not the correct word for it. Although the Stef
Mientki would probably be able to find it in the documentation it is not
as simple as you might think.
Most languages interpret a == b == 2 as (a == b) == 2, or throw an error
because this syntax is not valid. The fact that python understand the
obvious meaning of this code, is quite unique to Python, as far as I know.

 

[John Machin]

Hmm, 'of course' is not the correct word for it.

'Of course' was short for: Given alternative hypotheses H0 = "Python
feature" and H1 = "bug in Python compiler", one's instinct would be go
with H0 if a snap decision were required without time to refer to the
docs.

Although the Stef
Mientki would probably be able to find it in the documentation it is not
as simple as you might think.
Most languages interpret a == b == 2 as (a == b) == 2, or throw an error
because this syntax is not valid.

Indeed, some languages do ludicrous things with precedence of
relational operators. A compiler when faced with something like:
a == b and c == d
has at least two choices:
(1) (a == b) and (c == d) # seems rather useful
(2) (a == (b and c)) == d
which doesn't seem very useful at all. Pascal makes choice (2), which
is valid syntax only if b and c are booleans and if comparisons of
booleans are allowed (and IIRC Pascal didn't allow this).

The fact that python understand the
obvious meaning of this code, is quite unique to Python, as far as I know.

Indeed, Python isn't "some/most languages", which is why we're here.

 

[Steven D'Aprano]

Hmm, 'of course' is not the correct word for it.

Not at all. The Original Poster tried something, and it worked. There
were two alternatives:

(1) Writing a == b == 2 is valid.

(2) In the sixteen years that Python has been publicly available, with
tens of thousands or more developers using it, nobody had noticed that
Python had a bug in the compiler which incorrectly allowed a == b == 2
until Stef Mientki came along and discovered it.

Given those two alternatives, (2) would be very surprising indeed, and so
I think "of course" is well justified.

That Python allows chaining comparisons this way isn't really surprising.
That's a very natural thing to do. What's surprising is that other
languages *don't* allow chaining comparisons, but force you to write the
inefficient and (sometimes) confusing "(a == 2) and (b == 2)" instead.

 

[castironpi]

Not at all. The Original Poster tried something, and it worked. There
were two alternatives:

(1) Writing a == b == 2 is valid.

(2) In the sixteen years that Python has been publicly available, with
tens of thousands or more developers using it, nobody had noticed that
Python had a bug in the compiler which incorrectly allowed a == b == 2
until Stef Mientki came along and discovered it.

Given those two alternatives, (2) would be very surprising indeed, and so
I think "of course" is well justified.

That Python allows chaining comparisons this way isn't really surprising.
That's a very natural thing to do. What's surprising is that other
languages *don't* allow chaining comparisons, but force you to write the
inefficient and (sometimes) confusing "(a == 2) and (b == 2)" instead.

You see a couple of occurrences in natural language-- I'm wondering
where the majority of NL settles.
True

Do we do math on booleans on some level or in some contexts? Maybe a
"with syntaxchangeA:" is in the future.

 

[Colin J. Williams]

a == b == 2
is equivalent to
a == b and b == 2
except that b is only evaluated once for the whole comparison

Yes - there seems to be unanimity.

Comparisons can be chained arbitrarily,
e.g., x < y <= z is equivalent to x < y
and y <= z, except that y is evaluated
only once (but in both cases z is not
evaluated at all when x < y is found to
be false).

Formally, if a, b, c, ..., y, z are
expressions and opa, opb, ..., opy are
comparison operators, then a opa b opb c
....y opy z is equivalent to a opa b and
b opb c and ... y opy z, except that
each expression is evaluated at most once.

Colin W.