On Sep 26, 2019, at 19:34, Sébastien Eskenaz
Regarding parent class comparison, I would assume that there is a good reason to have made that class `MyStr` hence either some of its methods or attributes will end up being different from `str`.
It may just override some of the base methods, without adding any new ones, and without adding any attributes. And it will use the native string storage the same way as str (because you can’t really avoid that when subclassing str). So why shouldn’t it be equal? The default == for the str type will say it’s equal, so I think most people would expect the same from a more-lenient/more-wisely-usable equals function
So testing directly for the class is only a faster way to find the difference. I don't really see the problem with saying that objects of two different classes will always be different (unless the object implements its own `__eq__` function in which case the user can use the `==` operator). It's like comparing apples to oranges. They're bound to be different.
It’s like comparing Valencia oranges to oranges. All Valencia oranges are oranges. Pick up any Valencia oranges, and you’ve got an orange that’s equal to a Valencia orange. That’s exactly the same as MyStr and str, or bool and int, or any other subtype. In fact, isinstance(True, int), and for that matter, True == 1. Plus, even types that aren’t related can be equal: 1 == 1.0 == Fraction(1, 1).