On Fri, Sep 27, 2019 at 09:34:05AM +0700, Sébastien Eskenaz wrote:
I have a class `dataset` which can be built as follows: `mydata1 = dataset('path/to/dataset1')` Then I can create a second dataset `mydata2 = dataset('path/to/dataset1')` (no typo about `path/to/dataset1`, it is a 1). Thus testing `mydata1==mydata2` will return false while they actually contain the same information and data.
Do they? I have to believe you, because it is your class and you should know, but we can't make that assumption in general. It depends on what the dataset class does. For instance, think of: myfile1 = open('path/to/file') # some time later... myfile2 = open('path/to/file') Are they the same file? No. They point to the same *pathname*, but they are independent file objects. On Linux systems, they might not even end up reading from the same file on disk, for example: * path/to/file is a hard link to spam.txt * open('path/to/file') --> spam.txt * another process deletes path/to/file * then creates a new file at path/to/file. (Untested, but I'm pretty sure that will work.) Without knowing the internal details of your mydata1 and mydata2, there is no way that I can predict whether or not the two objects should compare as "the same". Which brings us to another point. What does "the same" mean? In Python, we have two well-defined operators for sameness: - the ``is`` operator, which tests for object identity (the two operands are the same object) - the ``==`` operator, which tests for value equality (the two operands have equal value) Javascript defines at least four different versions of "sameness" https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons... none of which are the same as either of Python's standard comparisons. What does your compare function do? Obviously it doesn't test for object identity, but it doesn't test for equality either since ``compare_objs(1, 1.0)`` will return False. I've now taken the time to read the whole function https://gist.github.com/SebastienEske/5a9c04e718becd93b7928514e80f0211 but the main thing that is missing is an explanation of *what it does*. If I call compare_objs(spam, eggs) and it returns True, what does that tell me about spam and eggs? Without having a good, solid description of the *meaning* of this comparison, it is difficult to tell whether it is useful in general or not, or whether other people would find it helpful as well as you.
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`.
Perhaps. But the *value* of the strings are still equal: MyStr("hello") and built-in string "hello" have the same sequence of characters and should be considered equal. But we've established that your comparison isn't an equality comparison.
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.
That depends on what you mean by "different". If the subclass is designed to obey the Liskov Substitution Principle, you ought to be able to substitute the subclass and the behaviour will remain the same. In other words, anything you can do with the string "hello", you should be able to do with MyStr("hello") -- they are identical in the limited sense of the Liskov Substitution Principle. So not so much like apples and oranges, but more like apples from one tree, and apples from another tree. Possibly from the same variety, or possibly not. -- Steven