3 ms·
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 'i
by 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 agoChecking 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 agoIt’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.