Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Skip Eq and Is replacement #162
(Sorry, this turned into a bit of a "think out loud" session)
I had thought about this one earlier, but I wasn't convinced that
(I can think of only one common case where
>>> x = float('NaN') >>> x != x True >>> x is not x False
While you technically can create classes that exhibit this behavior, it's such an oddity that many programmers have to be continually reminded that NaNs are never equal. Which is to say that I think
On the other hand, I can think of a vast number of examples where
Where things get really painful is with e.g. numbers. Consider:
>>> x = 1 >>> y = 1 >>> y == x True >>> y is x True >>> a = 12345678 >>> b = 12345678 >>> a == b True >>> a is b False >>>
These kinds of relationships are implementation-specific, probably version-specific, not promised or documented, and possibly dynamic. So no matter what strategy we choose WRT exceptions, we're in a hole.
Ultimately, I think the skip set is an interim solution. We'll really solve this with a robust exceptions system that lets users indicate when to avoid certain operators. We might also broaden the operator API e.g. by letting operator developers add metadata which could be filtered on. For instance, certain operators could be marked "often equivalent" or something, and users could choose to not apply those at all.
All of which is to say, I'll take this patch since it's probably really convenient for you and other users right now. I'm going to add a note to the skip set, though, indicating that it's an imperfect interim solution. Thanks for all of your work on this. It's really is great to get collaborators!
I think we should add some exclusions
cosmic rays change it to
and my test doesn't fail, how I should pass this situation
@proggga I agree that this mutation would be difficult for tests for detect, so another temporary exception is in order. Can you put together a PR for that?
If possible, I'd like the exception to be as tight as possible, only preventing mutation when
That just means to put create a Pull Request with the appropriate changes. We'll look them over, maybe requests changes, and then merge it in. You can read more about PRs in the github documentation.
(If you already know all of this, I don't mean to be rude or anything...I'm just not sure how much you know yet. I'll be happy to help you through the process if you need.)