Note: The attached image is a screenshot of page 31 of Dr. Charles Severance’s book, Python for Everybody: Exploring Data Using Python 3 (2024-01-01 Revision).


I thought = was a mathematical operator, not a logical operator; why does Python use

>= instead of >==, or <= instead of <==, or != instead of !==?

Thanks in advance for any clarification. I would have posted this in the help forums of FreeCodeCamp, but I wasn’t sure if this question was too…unspecified(?) for that domain.

Cheers!

 


Edit: I think I get it now! Thanks so much to everyone for helping, and @[email protected] and @[email protected] in particular! ^_^

  • _stranger_@lemmy.world
    link
    fedilink
    arrow-up
    24
    ·
    24 days ago

    It would be confusing and weird if “=” did different things depending on the context.

    = is the assignment operator

    == is the comparison operator.

    the others using = only is probably just to keep things short, and the fact that the context is a lot clearer with another character like < next to the =

    • rtxn@lemmy.world
      link
      fedilink
      English
      arrow-up
      8
      ·
      edit-2
      24 days ago

      Pascal uses = for comparison (and := for assignment), which confused the fuck out of me when I switched to C.

      • driving_crooner@lemmy.eco.br
        link
        fedilink
        arrow-up
        5
        ·
        24 days ago

        Some people in mathematics use := to assign functions, like f(x) := x^2; then when evaluating the function you use f(2) = 4, because it can be ser as a “true” comparison

        • rtxn@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          24 days ago

          I’ve never seen that, even in university, and it would be equally as confusing without explanation.

          • driving_crooner@lemmy.eco.br
            link
            fedilink
            arrow-up
            5
            ·
            24 days ago

            I only remember two of my professors using it, and I has to ask the first one what that mean and explain to my classmates on the second one.

    • EveryMuffinIsNowEncrypted@lemmy.blahaj.zoneOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      23 days ago

      It would be confusing and weird if “=” did different things depending on the context.

      That’s why I’m confused! It seems like it does!

      If I were to write the code

      x = 20
      print(x*2)
      

      it would execute as 40.

      But then the video turns around and says that == is equal to, not =.

  • FizzyOrange@programming.dev
    link
    fedilink
    arrow-up
    22
    ·
    24 days ago

    >= and <= match the mathematical operators. The question you want to ask is why doesn’t it use = for equality, and the answer is that = is already used for assignment (inherited from C among other languages).

    In theory a language could use = for assignment and equality but it might be a bit confusing and error prone. Maybe not though. Someone try it and report back.

    • owenfromcanada@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      ·
      24 days ago

      I’ve written code before in some hardware-specific languages before (I think it was for programming a stepper motor or something?) that used = for both assignment and comparison. If I recall correctly, the language was vaguely C-like, but assignment was not permitted in the context of a comparison. So something like if( a = (b+c) ) would not assign a value to a, it would just do the comparison.

    • Ephera@lemmy.ml
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      24 days ago

      Rust does an interesting thing in this regard. It does still have == for checking if two values are equal, but well, it actually doesn’t have a traditional assignment operator. Instead, it has a unification operator, which programmers usually call “pattern matching”.

      And then you can use pattern matching for what’s effectively an assignment and to some degree also for equivalence comparison.
      See a few examples here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1268682eb8642af925db9a499a6d587a

      • Successful_Try543@feddit.org
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        23 days ago

        This reminds me on the niche tool in Mathematica I’ve been using, which has four different assignment oparators for that purpose.

      • FizzyOrange@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        22 days ago

        It does still have a traditional assignment operator. You can assign values to mutable variables.

        Also I would say let-binds are still pretty much assignment; they just support destructuring. Plenty of languages support that to some extent (JavaScript for example) and you wouldn’t say they don’t have assignment.

        I don’t think it affects the ability to overload = anyway. I think there aren’t any situations in Rust where it would be ambiguous which one you meant. Certainly none of the examples you gave compile with both = and ==. Maybe there’s some obscure case we haven’t thought of.

    • EveryMuffinIsNowEncrypted@lemmy.blahaj.zoneOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      23 days ago

      I think what I’m most confused about is I cannot for the life of me seem to wrap my head around the difference between “assignment” and “equality”. They seem exactly the same to me: when a variable is assigned a value, it’s equal to that value now.

      Even if I were write the program

      x = 20
      print(x*2)
      

      it would still print 40. Because x is equal to 20. Because it was assigned the value of 20.

      Hell, I’ve even heard Dr. Severance say “equal to” in this context in earlier videos multiple times.

      • FizzyOrange@programming.dev
        link
        fedilink
        arrow-up
        7
        ·
        23 days ago

        They seem exactly the same to me: when a variable is assigned a value, it’s equal to that value now.

        Yeah it’s confusing because in maths they are the same and use the same symbol but they are 100% not the same in programming, yet they confusingly used the same symbol. In fact they even used the mathematical equality symbol (=) for the thing that is least like equality (i.e. assignment).

        To be fair not all languages made that mistake. There are a fair few where assignment is like

        x := 20
        

        Or

        x <- 20
        

        which is probably the most logical option because it really conveys the “store 20 in x” meaning.

        Anyway on to your actual question… They definitely aren’t the same in programming. Probably the simplest way to think of it is that assignment is a command: make these things equal! and equality is a question: are these things equal?

        So for example equality will never mutate it’s arguments. x == y will never change x or y because you’re just asking “are they equal?”. The value of that equality expression is a bool (true or false) so you can do something like:

        a = (x == y)
        

        x == y asks if they are equal and becomes a bool with the answer, and then the = stores that answer inside a.

        In contrast = always mutates something. You can do this:

        a = 3
        a = 4
        print(a)
        

        And it will print 4. If you do this:

        a = 3
        a == 4
        print(a)
        

        It will (if the language doesn’t complain at you for this mistake) print 3 because the == doesn’t actually change a.

        • EveryMuffinIsNowEncrypted@lemmy.blahaj.zoneOP
          link
          fedilink
          English
          arrow-up
          3
          ·
          21 days ago

          Ohhhhh! I think I get it now!

          So == means “equals” and is a declaration of the state of things, while = means "assigned the value of` and is a command toward a certain state of things. A description vs an action. An observation of a thing as opposed to effecting that thing.

          Is that about right?

          • itslilith@lemmy.blahaj.zone
            link
            fedilink
            arrow-up
            2
            ·
            edit-2
            21 days ago

            That’s exactly it. Some languages (e.g. Rust) make it even more clear¹, by following math notation for assignment even closer:

            let x = 5;
            

            ¹ simplified Rust a little bit, there’s a bit more nuance

          • FizzyOrange@programming.dev
            link
            fedilink
            arrow-up
            2
            ·
            21 days ago

            Well == is a question or a query rather than a declaration of the state of things because it isn’t necessarily true.

            You can write

            a = (3 == 4)
            

            which is perfectly valid code; it will just set a to be false, because the answer to the question “does 3 equal 4?” is no.

            I think you’ve got it anyway.

      • GetOffMyLan@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        22 days ago

        How would you check two variables have equal values without changing the value of one otherwise?

        Assignment you are assigning a value to the left side. Equality you are checking if the left and right are equal.

        It’s “set equal to” Vs “is equal to” one is an operation the other is a condition.

  • Avalokitesha@programming.dev
    link
    fedilink
    arrow-up
    11
    ·
    23 days ago

    My logic was always, if == is equal, then for >= we replace one of the equal signs to denote that it doesn’t have only be equal but can be both.

    But that was probably also influenced by languages where == means the value is equal and === means value and type have to be equal for the comparison to be true. If you compare “5” and 5 in those languages, == will be true and === will be false, since one is a string and one is a number.

    At the end of the day, those signs are arbitrary conventions. People agree on them meaning something in a specific context, and the same thing can mean different things in different contexts. A in English represents a different sound than A in Spanish, and sometimes even in other dialects of English. Thinking of out like that helped me to keep the conventions of different programming languages apart.

    • driving_crooner@lemmy.eco.br
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      22 days ago

      Don’t remember what language uses === to check if two objects have the same memory id assigned. Like a = 1, b= 1 would give true to a == b but false to a === b; while a = 1, b = a, would give true to both.

  • rtxn@lemmy.world
    link
    fedilink
    English
    arrow-up
    8
    ·
    edit-2
    24 days ago

    It’s a convention set by early programming languages.

    In most C-like languages, if (a = b)... is also a valid comparison. The = (assignment) operation returns the assigned value as a result, which is then converted to a boolean value by the if expression. Consider this Javascript code:

    let a = b = 1
    
    1. It first declares the b variable and assigns it the value of the expression 1, which is one.
    2. It returns the result of the expression b = 1, which is the assigned value, which is 1.
    3. It declares the a variable and assigns the previously returned value, which is 1.

    Another example:

    let a = 1
    let b = 2
    let c = 3
    console.log(a == b) // prints "false" because the comparison is false
    console.log(a = b) // prints 2 because the expression returns the value of the assignment, which is 'b', which is 2
    
    // Using this in an 'if' statement:
    if (b = c) { // the result of the assignment is 3, which is converted to a boolean true
        console.log("what")
    }
    

    You can’t do the same in Python (it will fail with a syntax error), but it’s better to adhere to convention because it doesn’t hurt anyone, but going against it might confuse programmers who have greater experience with another language. Like I was when I switched from Pascal (which uses = for comparison and := for assignment) to C.

  • rockSlayer@lemmy.world
    link
    fedilink
    arrow-up
    8
    ·
    24 days ago

    It’s still a mathematic operator. There’s an entire field of math dedicated to comparisons, and it’s featured heavily in most programming languages. Computer science is a field dedicated to the application of math

  • Successful_Try543@feddit.org
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    24 days ago

    <= is already no mathematical assignment operator, but a comparison operator. Thus there is no need to define e.g. <== for comparing two values.

  • WolfLink@sh.itjust.works
    link
    fedilink
    arrow-up
    5
    ·
    24 days ago

    It’s all convention coming from older programming languages, particularly C, which comes from programmers wanting shorthand for things like “BRANCH_EQUAL $1 $2 $3” which is shorthand for some binary code.

    Python has changed the logical and and or operators to be and and or instead of && and ||.

  • owenfromcanada@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    24 days ago

    Imagine saying these operators out loud.

    > is “is greater than”

    So it makes sense to use >= as “is greater than or equal to”

    You’d think = would be “is equal to”, but it’s already used for “set equal to” (i.e., assignment).

    So what symbol do we use for “is equal to”? The symbol used in many programming languages is ==, so Python chose to follow that convention.

    It’s worth noting that there are other languages that use = as “is equal to”, and use something else for assignment (like := for example). It just comes down to the history of the language and what conventions the original authors decided to use.

  • subignition@fedia.io
    link
    fedilink
    arrow-up
    3
    ·
    24 days ago

    If I were to speculate, I’d say it came from the == operator (Boolean equality comparison) and then later, when that was extended to include Boolean less-than-or-equal and greater-than-or-equal, the decision was made to keep them 2 characters long. Either because it was visually cleaner, or just because programmers love being lazy (read: efficient)

  • iii@mander.xyz
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    edit-2
    24 days ago

    I get your point of view, and haven’t thought about it that way before.

    As for why it’s like that, my best guess is the sentence I wrote above. Your proposal totally makes sense.