>>> class X:
... def __eq__(self, other): return True
...
>>> x = X()
>>> x is None
False
>>> x == None
True
I don't know Chris, doesn't this just show that If you construct a class with a, shall we say, "oddball" definition of ==, then using == on that class gets oddball results. And it goes without saying that we all understand that None and False and True (the dominant cases where PEP8 is forcing "is") will always have sensible definitions of ==.
I'm not saying == has to be used for everything or that it's not possible to construct a case where == is inappropriate . I'm saying PEP8 should permit using == where it works correctly. That's it. The cases where == works correctly are incredibly common.
If we has a class, say, where == has some weird behavior, the solution is that the docs for that class explain how its definition of == is weird and so code should take care to use "is" or whatever. That's kind of canonical use of Docs, right? Like describe the way in which this class does not act as you might expect. The solution is not to prohibit using == on the vast number of nice, regular classes where == works as expected.
Best,
Nick