Why = = (and not just =)

[Joe Green]

Sorry, I cant help aking stupid questions:

I understand why we need = = in C, but why in Python (or Java),
surely if you write
if a=b: pass # syntax error
it could not possibly mean anything other than what I intended
(which was of course if a = = b ?

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Sorry, I cant help aking stupid questions:

I understand why we need = = in C, but why in Python (or Java),
surely if you write
if a=b: pass # syntax error
it could not possibly mean anything other than what I intended
(which was of course if a = = b ?

Certainly, one could have use "=" to denote the test for equality.
However, I believe that this syntax was inherited from ABC, which
probably inherited it from C. In addition, it *is* useful to
syntactically distinguish between assignments and equality tests
even if the parser does not need that distinction: The human reader
might be tricked into seeing something that isn't there.

Regards,
Martin

 

[Peter Otten]

Sorry, I cant help aking stupid questions:

I understand why we need = = in C, but why in Python (or Java),
surely if you write
if a=b: pass # syntax error
it could not possibly mean anything other than what I intended
(which was of course if a = = b ?

I don't particularly like it, but you can chain assignments:
(2, 2)

HTH,
Peter

 

[Piet van Oostrum]

JG> Sorry, I cant help aking stupid questions:
JG> I understand why we need = = in C, but why in Python (or Java),
JG> surely if you write
JG> if a=b: pass # syntax error
JG> it could not possibly mean anything other than what I intended
JG> (which was of course if a = = b ?

So what about a = b = c vs. a = b==c?

 

[Alex Martelli]

Sorry, I cant help aking stupid questions:

I understand why we need = = in C, but why in Python (or Java),
surely if you write
if a=b: pass # syntax error
it could not possibly mean anything other than what I intended
(which was of course if a = = b ?

Well, it's quite conceivable it might mean != or <= -- as typos:
they're perfectly POSSIBLE, though not quite as LIKELY as the
typo you specifically made. One of Python's principles is: in
fact of ambiguity, resist the temptation to guess.

In PL/I, I remember, I could write...:

if if = then then then = else else else = if

the role of each word and punctuation was perfectly clear to
_the PL/I parser_ -- one '=' is equality, the other two are
assignment, one each of 'if' 'then' and 'else' are keywords
and the others are variable names...

Unfortunately humans aren't quite as smart, so allowing
ambiguous-to-humans constructs because they "could not
possibly mean anything other than" (whatever) turned out
to be terribly error-prone.

I believe just about all languages designed after PL/I
took stock of the lesson (pity that still today some
popular languages have roots in ones designed _before_
PL/I, such as Basic -- they may perpetuate some, though
probably not all, of these "ambiguity" mistakes).

In Python there are other excellent reasons why == is
needed to indicate equality testing in some cases, and
therefore it should be always used (rather than letting
you use = when context allegedly makes it unambiguous)
to avoid making Python a complicated, context-dependent
language. For example,

foo(fee, fie=fum)

passes a keyword argument fie with the value fum, while

foo(fee, fie==fum)

pasees a second positional argument, a bool, which is
True if fie equals fum, otherwise False.


Alex

 

[John Roth]

Sorry, I cant help aking stupid questions:

I understand why we need = = in C, but why in Python (or Java),
surely if you write
if a=b: pass # syntax error
it could not possibly mean anything other than what I intended
(which was of course if a = = b ?

Part of the reason is that Guido very seldom burns his bridges,
even after he's crossed them. Comparison and assignment are
different operators, and they deserve a different operator symbol.
Fortran started the trend of using the same symbol, but Fortran
was unrepentently statement oriented, and had a rather restricted
expression syntax to boot. The original language in the Algol family,
Algol 60, used ":=" as the assignment operator as I recall, a tradition
followed by Pascal.

Frankly, I'd rather have the assignment operator be something
like a left arrow: "<-" perhaps. I think it makes more sense,
and it avoids the confusion between one = and two.

It also allows the developers to add an assignment in expressions
sometime. Not that I think there's much hope of that, but it does
keep the options open.

John Roth

 

[Terry Reedy]

Sorry, I cant help aking stupid questions:

I understand why we need = = in C, but why in Python (or Java),
surely if you write
if a=b: pass # syntax error
it could not possibly mean anything other than what I intended
(which was of course if a = = b ?

It could also mean that the writer was trying to do assignment in an
expression, as one can do in C.

TJR

 

[Carlo v. Dango]

expression syntax to boot. The original language in the Algol family,

Algol 60, used ":=" as the assignment operator as I recall, a tradition
followed by Pascal.

Frankly, I'd rather have the assignment operator be something
like a left arrow: "<-" perhaps. I think it makes more sense,
and it avoids the confusion between one = and two.

actually Algol was meant to have the <- rather than the := but due to
problems writting the lexer/parser, it became :=

if you want a language which uses the <- operator then have a look at the
language "Beta" it takes a little getting used to, when used nested


-carlo van dango

 

[Dennis Lee Bieber]

John Roth fed this fish to the penguins on Sunday 19 October 2003 14:23
pm:

Fortran started the trend of using the same symbol, but Fortran
was unrepentently statement oriented, and had a rather restricted

Pardon? There is a great difference between = and .eq. in FORTRAN. F90
is the first standard Fortran I've seen that permitted symbols (=, <,

) in place of the dotted notation (.eq., .lt., .gt.)

Now, I'll be the first to admit that the syntax does have some rather
nasty look-ahead cases...

do 10 i = 2 . 9 3
vs
do 10 i = 2 , 9, 3

wherein the first is a floating point assignment to a variable named
"do10i", and the second as a loop to statement-label 10 with index "i"
-- and you can't parse the difference until you hit the "." or ","!

expression syntax to boot. The original language in the Algol family,
Algol 60, used ":=" as the assignment operator as I recall, a
tradition followed by Pascal.

And thereby transported into Ada (c.l.a currently has a flame going
from someone insisting Ada must include C-style assignments -- +=, etc.
-- to be viable... and some of the notation is now varying between +=
and :+ )


--

 

[John Roth]

John Roth fed this fish to the penguins on Sunday 19 October 2003 14:23
pm:


Pardon? There is a great difference between = and .eq. in FORTRAN. F90
is the first standard Fortran I've seen that permitted symbols (=, <,

But the dotted symbols came later. They weren't in the original Fortran's
in the 50s and 60s that I learned from...

The original Fortran was a syntactic mess - a large part of the impetus
for all the work on computer language syntax was caused by the
horrors of Fortran and COBOL syntax.

John Roth

 

[David Robinow]

Fortran started the trend of using the same symbol, but Fortran
was unrepentently statement oriented, and had a rather restricted
expression syntax to boot. The original language in the Algol family,
Algol 60, used ":=" as the assignment operator as I recall, a tradition
followed by Pascal.

You must be thinking of BASIC.
Fortran did no such thing. Originally, Fortran had only the arithmetic if, i.e.,
IF (A-B) 10, 20, 30

Later, the logical if was added,
IF (A .EQ. B) GO 20

 

[Dennis Lee Bieber]

John Roth fed this fish to the penguins on Sunday 19 October 2003 17:22
pm:

But the dotted symbols came later. They weren't in the original
Fortran's in the 50s and 60s that I learned from...

Hmmm, they existed in FORTRAN IV (1966 standard). I'll have to concede
that what F-II had I wouldn't know...


--

 

[Hans Nowak]

Sorry, I cant help aking stupid questions:

I understand why we need = = in C, but why in Python (or Java),
surely if you write
if a=b: pass # syntax error
it could not possibly mean anything other than what I intended
(which was of course if a = = b ?

But it leads to ambiguities in other situations... a = b = c, for example.

Interestingly, very old versions of Python did use = as the equality operator.
See Misc/HISTORY in the source distribution:

New features in 0.9.6:
[...]
- '==' is now the only equality operator; "../demo/scripts/eqfix.py" is
a script that fixes old Python modules

Release 0.9.3 (never made available outside CWI)
[...]
- C comparison operators: == != (the old = and <> remain valid).

ABC apparently used = as well, and <> for inequality. I'm assuming this is
where the first versions of Python got it from. Judging from the history file,
= was soon replaced by ==; <> is still valid today, but deprecated in favor of !=.

Cheers,

 

[Duncan Booth]

Frankly, I'd rather have the assignment operator be something
like a left arrow: "<-" perhaps. I think it makes more sense,
and it avoids the confusion between one = and two.

This would be just as ambiguous as making both assignment and comparison
use '='. Compare:

a<-b<-c

a=b=c

 

[John Roth]

This would be just as ambiguous as making both assignment and comparison
use '='. Compare:

a<-b<-c

a=b=c

1. I didn't suggest using the same symbol for both.

2. I'm quite well aware of the syntactic issue in Python. Unfortunately,
there
aren't any good solutions without adding extra symbols that aren't on the
keyboard.

John Roth

 

[Thomas Mailund]

actually Algol was meant to have the <- rather than the := but due to
problems writting the lexer/parser, it became :=

if you want a language which uses the <- operator then have a look at the
language "Beta" it takes a little getting used to, when used nested

Actually, if I recall correctly, BETA <URL:http://www.daimi.au.dk/~beta/>
uses the "->" operator--assignment goes the other way.

In BETA there's syntactical difference between assignment and equality
tests (= for testing equality, -> for assigning), but assignment and
method calls uses the same syntax. So assigning to variable x, and
calling function f, uses the same operator:

5 -> x; 5 -> f;


Just nitpicking...

/mailund

 

[Sean Ross]

Sorry, I cant help aking stupid questions:

I understand why we need = = in C, but why in Python (or Java),
surely if you write
if a=b: pass # syntax error
it could not possibly mean anything other than what I intended
(which was of course if a = = b ?

Well, it could mean "if the value of a is True, after being assigned the
value of b" (which is what it would mean in C/C++, Java, and several other
languages). So, I suppose "==" is used to distinguish between assignment(or
binding) and tests for equality. I suppose the question you could ask
yourself as a language designer is "Is it preferrable to require different
notation for these different operations, or to use the same notation and
have its semantics differ depending upon the context in which it appears?".
In Python, they've chosen the former. I think there are languages that use
the latter, but none come to mind at the moment. Since Python does not allow
assignment in expressions, it's seems reasonable that your suggestion could
be introduced, but I hazard to guess that it would introduce more confusion
than clarity. For instance, people familiar with C/C++, Java, etc. (and even
many who are not familiar with those languages) will have very different
expectations of what "if a = b:" should mean. In fact, there are frequent
requests on this newsgroup for that expression to take on the meaning it has
in those other languages, rather than result in an exception, as it does in
this one (see
http://www.python.org/doc/faq/general.html#why-can-t-i-use-an-assignment-in-an-expression).
In an alternate version of the faq (located here:
http://python.is.co.za/doc/faq/general.html#why-can-t-i-use-an-assignment-in-an-expression),
there is mention of introducing ":=" for assignment. If you had that, then
you could use "=" as a test for equality with a bit less confusion. Of
course, everyone would have to go back through their old code and change
their "a=b"s to "a:=b", and all of their "a==b"s to "a=b". Hmm. And I
suppose you might want to change "+=", "-=", etc. to "+:=", "-:=", etc. for
symmetry ... on second thought ... maybe not. Anyway, after all of that, the
answer to your question "Why do we need == in Python?" is "We don't, really,
but that's what Guido wanted/chose". At least, I don't believe we _need_
it - I think it would be possible to design the language to interpret "a=b"
as a test for equality, when found in an expression, and as assignment, when
it is not. But they haven't done that in Python, and it doesn't seem likely
that it will be done. I don't have a problem with that. I like the way it's
done now. But, of course, tastes will vary.

Was that at all helpful?
Sean