
Hi Why does Python use the equal sign (=) to mean assignment, and use two equal signs (==) to mean equality? Equality and assignment are not the same, yet the meaning of the equal sign is universally understood, so why redefine its meaning? I know other languages like Java and C++ employ this convention too, but how does one explain the logic behind this approach? I'll readily admit to a bias: when I see the notation ':=' in languages like Pascal, Smalltalk or Eiffel etc, I can at least understand the distinction these languages attempt to impart to the user that equality and assignment are similar, but distinct concepts. It may seem a trivial point to bring up, but while I can explain the difference between equality and assignment, I cannot explain the logic of using the '=' and '==' notation. Thanks :-) Regards - Josh M. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

On Sunday 07 April 2002 01:04 pm, Josh McKenzie wrote:
Hi
Why does Python use the equal sign (=) to mean assignment, and use two equal signs (==) to mean equality? Equality and assignment are not the same, yet the meaning of the equal sign is universally understood, so why redefine its meaning?
Python likes to be spare with punctuation, so not surprising it doesn't go for the standard PL/1 style alternative a := 3 (with colon) for assignment, just as it drops enclosing block braces (uses indentation) and semi-colon line terminators (optional if you want more than one statement per line). APL had its own character set and so used <- (arrow) for assignment.
I know other languages like Java and C++ employ this convention too, but how does one explain the logic behind this approach?
Very simply: notations come and go; it's the ideas that are important. If you have a difference, and a way of notating this difference, then you're done. Note that math books sometimes use the equal sign for assignment, and sometimes to assert equivalence. We're supposed to know the different from context. Parsers don't like 'context' so much -- better to be explicit. The use of a double equal makes sense in the light of other combos e.g. <= >= and !=. Kirby
I'll readily admit to a bias: when I see the notation ':=' in languages like Pascal, Smalltalk or Eiffel etc, I can at least understand the distinction these languages attempt to impart to the user that equality and assignment are similar, but distinct concepts.
It may seem a trivial point to bring up, but while I can explain the difference between equality and assignment, I cannot explain the logic of using the '=' and '==' notation.
Thanks :-)
Regards - Josh M.
_________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig

On Sun, Apr 07, 2002 at 05:04:19PM +0000, Josh McKenzie wrote:
It may seem a trivial point to bring up, but while I can explain the difference between equality and assignment, I cannot explain the logic of using the '=' and '==' notation.
I assume that Python inherited this behavior from C/C++ or some other languages, as you indicated. The only language I can think of where there was an independent justification for the syntax was BASIC, where one could write: 10 LET X = 20 which takes its cue from mathematical prose. The LET was optional, so this was universally shortened to 10 X = 20 and the confusion began. That's my theory. Dustin -- Dustin Mitchell dustin@ywlcs.org http://people.cs.uchicago.edu/~dustin/

Josh McKenzie writes:
Hi
Why does Python use the equal sign (=) to mean assignment, and use two equal signs (==) to mean equality? Equality and assignment are not the same, yet the meaning of the equal sign is universally understood, so why redefine its meaning?
I know other languages like Java and C++ employ this convention too, but how does one explain the logic behind this approach?
I'll readily admit to a bias: when I see the notation ':=' in languages like Pascal, Smalltalk or Eiffel etc, I can at least understand the distinction these languages attempt to impart to the user that equality and assignment are similar, but distinct concepts.
It may seem a trivial point to bring up, but while I can explain the difference between equality and assignment, I cannot explain the logic of using the '=' and '==' notation.
Thanks :-)
In some languages, these have to be distinguished because the assignment operator can be used in an expression. E.g. in C you can say if (myflag = result()) or if (myflag == result()) and each of these is a potentially useful statement with a distinct meaning. The first is equivalent to myflag = result(); if (myflag) and the second is more obvious (checking whether the value returned from result() is equal to the existing value of myflag). The first idiom is often used in cases where something can return NULL or 0 to indicate failure: if ((f = fopen("foo")) != NULL) { ... } if ((m = malloc(n*sizeof(blah)) != NULL) { ... } (NULL is like Python's None.) Even in languages where assignment has to be a statement of its own, and can't be part of a larger expression, you could have confusion in the opposite direction. Many languages permit values (like integers or strings) and expressions which return them to stand on their own as statements. For example, "4" is a valid statement in Python (as well as in C). print "Hello, world!" 4 print "That had no effect on the execution of this program!" Because of this rule, a complex expression can also be a legal statement: print "Get ready for two irrelevant tests!" 2 + 2 == 4 9 < 12 print "Did you notice anything? I didn't, either." And that means that a test for equality can be a statement. Again: x = 1 print "This is amusing!" x**2 + 7*x + 53 == 1/3 print "That had no effect either!" So if Python didn't distinguish between assignment and equality, this program would be unambiguous x = 5 print "Hello" x < 6 print "Goodbye" Yet this program would be ambiguous: x = 5 print "Hello" x = 6 # does this mean "x == 6"? or "x = 6"? print "Goodbye" Distinguishing them allows more consistent application of the principle that _any expression_ can be a statement of its own. The choice of "==" and "=" rather than "=" and ":=" is just a matter of typography. The use of ":=" has older academic roots, and the use of "==" is traditional in C (and perhaps Kernighan and Ritchie found it in an earlier language like BPCL). There's an analogy to mathematicians' attempt to distinguish between defined equality and assumed, deduced, or hypothesized equality. If a mathematician says that _as a matter of notation_ I will define this symbol to mean this expression, it's in some sense a different kind of activity from talking about the proposition that two expressions are equal. So some mathematicians use a different symbol for defined equality and numeric equality. To put it one more way, a mathematician might say that "x = 2" is an _assertion_, which could be true or false, where "x := 2" is more like a performative, which causes a result and which is not itself true or false. I'm sure there's some interesting academic discussion of this going back to the 1950s and 1960s, but I haven't encountered much of it. -- Seth David Schoen <schoen@loyalty.org> | Reading is a right, not a feature! http://www.loyalty.org/~schoen/ | -- Kathryn Myronuk http://vitanuova.loyalty.org/ |

There is no logic to it. When we started coding programming languages, "=" was in the character set and it was used for assignment. It started with Fortran and earlier efforts at programming languages. Since Fortran didn't have relational operators in the first version, there was no problem. In later versions, .EQ. was used for the relational operator, allowing Fortran to remain expressible in the original 48-character set. When there were relational operators and they needed to be different, the conventions of ":=" and "=" (Algol family) and "=" and "==" (the Ratfor family) arose. The use of := (and =:) to indicate a composed arrow just didn't set well with some people. I've always liked it myself. There may be some odd connection with ":" not being available in all character sets at the time these practices were being worked out. In some languages where there is no possible confusion of assignment and the equality relational operator, "=" is used both ways. It is arbitrary. Simply arbitrary. Both operations are needed, and their symbols usually need to be distinct. That's the whole deal. Basically, "==" is now the prevailing custom for the equality relational operator in programming languages. Since mathematics doesn't have an assignment operator, and mathematicians are willing to use other symbols (e.g., arrows) when needed, we are stuck with this odd cross-over dissonance. Math teachers here can tell us whether "==" is creeping into their discipline, and how students adjust to the different senses of "=" in school. -- Dennis -----Original Message----- From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On Behalf Of Josh McKenzie Sent: Sunday, April 07, 2002 10:04 To: edu-sig@python.org Subject: [Edu-sig] Equality and Assignment Notation Hi Why does Python use the equal sign (=) to mean assignment, and use two equal signs (==) to mean equality? Equality and assignment are not the same, yet the meaning of the equal sign is universally understood, so why redefine its meaning? I know other languages like Java and C++ employ this convention too, but how does one explain the logic behind this approach? I'll readily admit to a bias: when I see the notation ':=' in languages like Pascal, Smalltalk or Eiffel etc, I can at least understand the distinction these languages attempt to impart to the user that equality and assignment are similar, but distinct concepts. It may seem a trivial point to bring up, but while I can explain the difference between equality and assignment, I cannot explain the logic of using the '=' and '==' notation. Thanks :-) Regards - Josh M. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
participants (5)
-
Dennis E. Hamilton
-
Dustin Mitchell
-
Josh McKenzie
-
Kirby Urner
-
Seth David Schoen