Every time I write a `class` statement in Python now, I wonder about this: https://blog.glyph.im/2023/02/data-classification.html
@glyph You asked why not all classes should be dataclasses: My first thought was about defaults: The __eq__ default of the dataclass (which says that it's equal when the values are equal) is unlike how normal classes work and unexpected.
And this becomes a bigger problem when you use @property to set values.
@mborus in my ideal world this would raise an exception since this class doesn’t have a __c attribute
@mborus how "unexpected"? this is what the distinction between `is` and `==` is for.
@glyph You have a point there, I should use "is" instead of "==" to compare for equal
Unexpected just because "==" ususally worked like "is" unless it's defined differently.
@mborus `==` is supposed to mean "value equality" whereas `is` is supposed to mean "mutability equality". built-in types follow this convention, so why are user-defined types confusingly different?
>>> x = [1, 2, 3]
>>> y = [1, 2, 3]
>>> a = {1: 2, 3: 4}
>>> b = {1: 2, 3: 4}
>>> print(x == y)
True
>>> x.append(1)
>>> print(x == y)
False
>>> print(a == b)
True
>>> b[5] = 6
>>> print(a == b)
False
@glyph Good question.
I don't know why this was chosen. If I had to guess using "is" as a default for "__eq__" is easy to implement and guaranteed that there's always a result to "==".
I always treat "==" as "whatever __eq__ says or defaults to" and changed it for some of my own classes.
To check I looked up the docs (https://docs.python.org/release/3.11.2/library/stdtypes.html#comparisons) and "==" is just defined as "equal" (with no concrete definition what that actually means and the class default of "is" is mentioned)
