4 ms·

> That is suprising! It turns out that all “small integers” with the same value point to the same memory. We can use the Python built-in function id which retur

> That is suprising! It turns out that all “small integers” with the same value point to the same memory. We can use the Python built-in function id which returns a value you can think of as a memory address to investigate. Unfortunately this blog post seems to miss a great opportunity to show you how you should compare integers for equality -- using the equality operator `==` and not the identity comparison `is`. EDIT: odd, this post attracted a lot of downvotes. Please help me learn how this post could be improved.

dvfjsdhgfv 9y ago
Frankly, what's the point? This is common knowledge.
int_19h 9y ago
It never ceases to amaze me that Python seems to be the only one that got this right - namely, that == should have value comparison semantics, for all types, and that some other (preferably distinctive enough, rather than something like ===) operator should always compare references. Then you look at something like C#, where == compares values for value types and references for reference types, except that == is overloaded for some "value-like" reference types like String... it's a mess. OTOH, Java is consistent in a sense that == never dereferences, but awkward in practice because of the need to use equals() for strings, which is too verbose for an operation that's far more common than object identity comparison.
- andrewjw 9y ago
  Correct me if I'm wrong, but doesn't C++ use == for value comparison?
  - alphaalpha101 9y ago
    C++ uses `==` for whatever you want. But generally in C++, user-defined types will be documented as either having 'reference semantics' or 'value semantics' and all aspects of the type will conform to that.
    - int_19h 9y ago
      In C++, == pretty much always uses value semantics regardless, because reference semantics are pretty much always explicit (dereference with star etc).
      - andrewjw 9y ago
        I think you mean reference with & (e.g. &x == &y)
        int_19h 9y ago
        No, I mean dereference if what you have are reference types (i.e. pointers in C; I'm using Java terminology here, since that's the baseline for comparison) to begin with, which is equivalent to the situation in Java. E.g. to copy the referenced object, you need to do x = y, while x = y copies the reference (pointer) itself. Similarly, when you compare, x == y compares the referenced objects, while x == y compares the references (pointers). And even for member access, you have to do (*x).foo, or the equivalent syntactic sugar x->foo.
- cortesoft 9y ago
  Ruby does it, too (== is for value comparison, while .equal? is for reference comparison)
- lmm 9y ago
  It's still confusing in Java because there are primitive types which == compares by value. Scala gets it right: == does the right thing and there's some operator I never use (I think it's "eq"?) if you really want reference comparison.
  - int_19h 9y ago
    In Java it's not confusing when you realize that == always compares values (i.e. things that can be stored in variables); it's just that for reference types, the values are references. It'd be more obvious if Java required explicit dereferencing like C++ does, but it's still consistent. Just not convenient.
    - lmm 9y ago
      > In Java it's not confusing when you realize that == always compares values (i.e. things that can be stored in variables); it's just that for reference types, the values are references. It's still confusing. Plenty of "reference types" behave like values in all obvious senses. Why should "foo" be a reference but 45L a value?
      - pjmlp 9y ago
        Because "foo" is an instance of String, aka subclass of Object, while 45L is a value for the primitive type long. I fail to see the confusion, other than for newbies.
        simon_o 9y ago
        That's pretty much saying "it is the way it is", which a) is not even true, see floating point numbers and b) will be obsolete with value types. Needless to say, there is pointless confusion created by Java's design, and there are better approaches available. All you have to do is to adapt the semantic model from reference equality vs. value equality to identity vs. equality. Identity checks whether the "bits" are identical, irregardless of whether the bits are "references" or values, and equality is a user-defined operation. "Foo" equality "Foo" // True "Foo" identity "Foo" // Only true if they point to the same "object" 123 equality 123 // True 123 identity 123 // True Double.NaN equality Double.NaN // False Double.NaN identity Double.NaN // True Which symbols you pick for "equality" and "identity" is largely arbitrary.

dvfjsdhgfv 9y ago

Frankly, what's the point? This is common knowledge.

int_19h 9y ago

It never ceases to amaze me that Python seems to be the only one that got this right - namely, that == should have value comparison semantics, for all types, and that some other (preferably distinctive enough, rather than something like ===) operator should always compare references. Then you look at something like C#, where == compares values for value types and references for reference types, except that == is overloaded for some "value-like" reference types like String... it's a mess. OTOH, Java is consistent in a sense that == never dereferences, but awkward in practice because of the need to use equals() for strings, which is too verbose for an operation that's far more common than object identity comparison.

andrewjw 9y ago
Correct me if I'm wrong, but doesn't C++ use == for value comparison?
- alphaalpha101 9y ago
  C++ uses `==` for whatever you want. But generally in C++, user-defined types will be documented as either having 'reference semantics' or 'value semantics' and all aspects of the type will conform to that.
  - int_19h 9y ago
    In C++, == pretty much always uses value semantics regardless, because reference semantics are pretty much always explicit (dereference with star etc).
    - andrewjw 9y ago
      I think you mean reference with & (e.g. &x == &y)
      - int_19h 9y ago
        No, I mean dereference if what you have are reference types (i.e. pointers in C; I'm using Java terminology here, since that's the baseline for comparison) to begin with, which is equivalent to the situation in Java. E.g. to copy the referenced object, you need to do x = y, while x = y copies the reference (pointer) itself. Similarly, when you compare, x == y compares the referenced objects, while x == y compares the references (pointers). And even for member access, you have to do (*x).foo, or the equivalent syntactic sugar x->foo.
cortesoft 9y ago
Ruby does it, too (== is for value comparison, while .equal? is for reference comparison)
lmm 9y ago
It's still confusing in Java because there are primitive types which == compares by value. Scala gets it right: == does the right thing and there's some operator I never use (I think it's "eq"?) if you really want reference comparison.
- int_19h 9y ago
  In Java it's not confusing when you realize that == always compares values (i.e. things that can be stored in variables); it's just that for reference types, the values are references. It'd be more obvious if Java required explicit dereferencing like C++ does, but it's still consistent. Just not convenient.
  - lmm 9y ago
    > In Java it's not confusing when you realize that == always compares values (i.e. things that can be stored in variables); it's just that for reference types, the values are references. It's still confusing. Plenty of "reference types" behave like values in all obvious senses. Why should "foo" be a reference but 45L a value?
    - pjmlp 9y ago
      Because "foo" is an instance of String, aka subclass of Object, while 45L is a value for the primitive type long. I fail to see the confusion, other than for newbies.
      - simon_o 9y ago
        That's pretty much saying "it is the way it is", which a) is not even true, see floating point numbers and b) will be obsolete with value types. Needless to say, there is pointless confusion created by Java's design, and there are better approaches available. All you have to do is to adapt the semantic model from reference equality vs. value equality to identity vs. equality. Identity checks whether the "bits" are identical, irregardless of whether the bits are "references" or values, and equality is a user-defined operation. "Foo" equality "Foo" // True "Foo" identity "Foo" // Only true if they point to the same "object" 123 equality 123 // True 123 identity 123 // True Double.NaN equality Double.NaN // False Double.NaN identity Double.NaN // True Which symbols you pick for "equality" and "identity" is largely arbitrary.