The only reason I can think of why you are so resistant to this would be due to poor development practices, e.g. adding tests long after the "main" code has already been deployed, or having a separate team write tests.
and even then, maybe monkey-patch an __eq__ in for your tests?
For my part, I have for sure defined __eq__ for no other reason than tests -- but I'm still glad I did.
Though perhaps the idea (sorry, not sure who to credit) of providing a utility for object equality in the stdlib, so that in the common case, it would be simple to write a "standard" __eq__ would be nice to have.
(note on that -- make sure it handles properties "properly" -- if that's possible)
In fact, defining `__hash__` as returning the constant `42` is better, because it is fine if two objects that *don't* compare equal still have the same hash value (but not the other way around).
Really? can anyone recommend something to read so I can "get" this -- it's counter intuitive to me. Is __eq__ always checked?!? I recently was faced with dealing with this issue in updating some old code, and I'm still a bit confused about the relationship between __hash__ and __eq__, and main Python docs did not clarify it for me.
Finally, dataclasses get you all this for free, and they are the future.
That is a great point -- I've learned that the really nice thing about dataclasses is that they keep a separate structure of all the attributes that matter, and some metadata about them -- type, etc. This is really useful, and better (or at least more stable) than simply relying on __dict__ and friends.
I'm thinking that a "dataclasstools" package that builds on dataclasses, would be really nice -- clearly something to start on PyPi, but as a unified effort, we could get something cleaner than everyone building their own little bit on their own.
-CHB