5 ms·
That Python uses the exact same string if they contain the same immutable content can probably be a bit confusing. But if you want truly confusing behavior look
by bjarneh 4y ago
That Python uses the exact same string if they contain the same immutable content can probably be a bit confusing. But if you want truly confusing behavior look at how Java treats numbers wrapped in their object type:
public class Main{
public static void main(String[] args){
Integer a = 300;
Integer b = 300;
System.out.printf(" %s == %s: %s\n", a, b, (a == b));
a = 100;
b = 100;
System.out.printf(" %s == %s: %s\n", a, b, (a == b));
}
}
// output
300 == 300: false
100 == 100: true
When combined with Java's auto-boxing, this can create some serious confusion
- tekknolagi 4y agoCPython does this too (`is` is roughly the same as Java's `==`): >>> a = 300 >>> b = 300 >>> a is b False >>> a = 100 >>> b = 100 >>> a is b True >>> CPython has a small set of canonical objects for integers.
- bjarneh 4y agoLuckily you don't typically compare numbers in Python with 'is'. In Java you should not compare Integer objects with '==' either of course, but '==' is typically used with numbers, and the auto-boxing features of Java makes it very easy to shoot your self in the foot with this stuff. I once ran into a bug which had been there for years, since some Integer values had never crept over that magic limit, and auto-boxing allowed the numbers to be treated as int's all over, so it really took me some time to figure out what was going on...
- deleted 4y ago[deleted]
- jreese 4y agoThis is only true for string literals. Strings constructed at runtime may (and often will) end up as separate objects: >>> a = "this is a long sentence in a string literal" >>> b = "this is a long" + " sentence in a " + "string literal" >>> a is b False >>> id(a) 4386376272 >>> id(b) 4387721264 >>> a == b True
- bjarneh 4y agoThose two strings aren't equal though, missing some spaces in b :-)
- jreese 4y agoOops! Thanks for catching that. I fixed the example.
- deleted 4y ago[deleted]
- masklinn 4y agoBeware that your method of construction is risky to your demonstration: the python compiler does do some limited optimisations, and trivial constant folding is one of them. If you test at the shell it apparently misses it (though it works for smaller strings e.g. "abc" / "a" + "b" + "c"), but if you put the same thing in a file and run it, it'll tell you the two strings are identical.
- deleted 4y ago[deleted]
- Woden501 4y agoWait this is confusing for anyone beyond a fresh-faced junior dev? An Integer is an object while 100 is a primitive. Of course two different objects aren't going to be equal since they're literally not the same object. Two primitives of the same value will be though because they are the same primitive. It's exactly the same behavior across many languages. This right here is why it's critical to have developers of all levels across a team. Those of use who have been doing this long enough don't remember what caused us issues as juniors. We need the mid-levels to translate and remind us of these things lol
- philote 4y agoIt's confusing because using 100 works fine; both are seen as the same object. But using a number over 256 causes it to fail to see both as the same object. Of course, as an experienced dev, I would never use "is" for comparing integers, only for comparing things I know are objects that may otherwise be equal in value.
- bjarneh 4y ago> An Integer is an object while 100 is a primitiv They are both objects; they only differ in size.