Confused about logical operators (i.e. "comparison operators", or "boolean operators") in Python (lemmy.blahaj.zone)

submitted 6 months ago* (last edited 6 months ago) by EveryMuffinIsNowEncrypted@lemmy.blahaj.zone to c/python@programming.dev

33 comments fedilink hide all child comments

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 @FizzyOrange@programming.dev and @itslilith@lemmy.blahaj.zone in particular! ^_^

you are viewing a single comment's thread
view the rest of the comments

[-] Ephera@lemmy.ml 3 points 6 months ago* (last edited 6 months 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

[-] FizzyOrange@programming.dev 2 points 6 months ago* (last edited 6 months 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.