4 ms·

I agree with most of your points, because in most cases, people try something very weird, and they are surprised that the result is something even weirder (or t

I agree with most of your points, because in most cases, people try something very weird, and they are surprised that the result is something even weirder (or they just didn't think through the example logically). Except the string comparison with "is". It's confusing, because there are no errors, and when I try them in the Python REPL, it "works". The code is logical, I tested the example and it works... ...except when it doesn't, but if I'm just a naive beginner, I'll need to learn the hard way that it doesn't always work For this reason, I'd be okay with saying that "it" for strings is a WTF of the language.

Doxin 6y ago
The confusion there is caused by english not disambiguating between equality and being-the-exact-same-thing-ness. I'll grant that "is" is a bit of a footgun for new users, but it's not a WTF in the sense that the language is doing something weird. Rule of thumb is use == for everything except True/False/None. Once you get going with python you'll learn the meaning of is eventually, and you'll still barely ever need to use it.
- GoblinSlayer 6y ago
  Why that exception?
  - maweki 6y ago
    None, True, False are singletons and are never constructed again after initilization of the interpreter (and have been keywords in python2). That's why "is" is always safe. Small integers, as they are kept around, probably are as well (5 is (2+3) works). I think what gets dropped during the conversation is, that we've been living with Java doing it this way (is being == and == being .equals) for decades and nobody really complains.
    - deleted 6y ago
      [deleted]
    - GoblinSlayer 6y ago
      I mean why not use == for everything?
      - Vaphell 6y ago
        1. it's a slower check, just like equals() intended for value equality is slower than reference equality == in java. 2. 1 == True and 0 == False, as booleans subclass the int type. On the other hand is distingushes between 1 and True, and 0 and False respectively.
- EForEndeavour 6y ago
  Noob question: instead of using == except for True/False/None, what about just using == for all comparisons?
PartiallyTyped 6y ago
In python, strings are mostly unique, meaning that a string can be bound on many variables, and all the variables point to the same string. This is where the 'is' operator comes in, 'is' checks for reference equality, that is, the object that is bound onto the two variables is the same. If they are not the same, 'is' fails. In other words: x = "foo" y = "foo" x == y and x is y Both strings point to the same exact memory. Hence, 'is' works. But it isn't always true: x = "foo" y = f"{x} "[:-1] # get everything but the space x == y # True y is x # False
- watt 6y ago
  Checking for reference equality (comparing pointers) is such a niche requirement it should be hidden behind stronger syntactic vinegar. The greatest mistake Java made maybe is having == for testing pointers, and .equals() function for actually comparing. Every JVM language that came after Java reverses this. Here, "is" simply is too nice. Should've named it something nobody will accidentally use.
  - deleted 6y ago
    [deleted]
  - masklinn 6y ago
    > Checking for reference equality (comparing pointers) is such a niche requirement it should be hidden behind stronger syntactic vinegar. In python it’s common due to `None`, which you really want to check by identity. Other placeholders as well. This is such a major use case that in 3.9 `is` was moved out of the generic `compare_op` instruction and into its own. And because __eq__ can be overridden, aside from being noticeably slower `x == None` is not truly reliable.
  - IgorPartola 6y ago
    It’s not even that. CPython happens to sue memory address as ID, but the language doesn’t require that. You could easily use something else for the object ID and get completely different behavior.

Doxin 6y ago

The confusion there is caused by english not disambiguating between equality and being-the-exact-same-thing-ness. I'll grant that "is" is a bit of a footgun for new users, but it's not a WTF in the sense that the language is doing something weird. Rule of thumb is use == for everything except True/False/None. Once you get going with python you'll learn the meaning of is eventually, and you'll still barely ever need to use it.

GoblinSlayer 6y ago
Why that exception?
- maweki 6y ago
  None, True, False are singletons and are never constructed again after initilization of the interpreter (and have been keywords in python2). That's why "is" is always safe. Small integers, as they are kept around, probably are as well (5 is (2+3) works). I think what gets dropped during the conversation is, that we've been living with Java doing it this way (is being == and == being .equals) for decades and nobody really complains.
  - deleted 6y ago
    [deleted]
  - GoblinSlayer 6y ago
    I mean why not use == for everything?
    - Vaphell 6y ago
      1. it's a slower check, just like equals() intended for value equality is slower than reference equality == in java. 2. 1 == True and 0 == False, as booleans subclass the int type. On the other hand is distingushes between 1 and True, and 0 and False respectively.
EForEndeavour 6y ago
Noob question: instead of using == except for True/False/None, what about just using == for all comparisons?

PartiallyTyped 6y ago

In python, strings are mostly unique, meaning that a string can be bound on many variables, and all the variables point to the same string. This is where the 'is' operator comes in, 'is' checks for reference equality, that is, the object that is bound onto the two variables is the same. If they are not the same, 'is' fails. In other words: x = "foo" y = "foo" x == y and x is y Both strings point to the same exact memory. Hence, 'is' works. But it isn't always true: x = "foo" y = f"{x} "[:-1] # get everything but the space x == y # True y is x # False

watt 6y ago
Checking for reference equality (comparing pointers) is such a niche requirement it should be hidden behind stronger syntactic vinegar. The greatest mistake Java made maybe is having == for testing pointers, and .equals() function for actually comparing. Every JVM language that came after Java reverses this. Here, "is" simply is too nice. Should've named it something nobody will accidentally use.
- deleted 6y ago
  [deleted]
- masklinn 6y ago
  > Checking for reference equality (comparing pointers) is such a niche requirement it should be hidden behind stronger syntactic vinegar. In python it’s common due to `None`, which you really want to check by identity. Other placeholders as well. This is such a major use case that in 3.9 `is` was moved out of the generic `compare_op` instruction and into its own. And because __eq__ can be overridden, aside from being noticeably slower `x == None` is not truly reliable.
- IgorPartola 6y ago
  It’s not even that. CPython happens to sue memory address as ID, but the language doesn’t require that. You could easily use something else for the object ID and get completely different behavior.