> > >>> 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 On Mon, Aug 30, 2021 at 2:24 PM Chris Angelico <ros...@gmail.com> wrote: > On Tue, Aug 31, 2021 at 7:17 AM Nick Parlante <n...@cs.stanford.edu> > wrote: > >> > >> On what basis do you ascertain whether "==" would work correctly? > >> Please explain. > > > > > > Hi Chris, I'm just glancing at the line of code, and doing a little > thought experiment to see if it would get the same output if == was used > instead. For a singleton like None or False or the class like "list" .. == > will return the same answer as "is". Look at these lines; > > > > if mode is None: > > if type(items) is list: > > > > If that code works with "is" it's going to work with == too. People are > not used to seeing == in these cases, but it works: > > > > >>> x = None > > >>> x is None > > True > > >>> x == None > > True > > >>> > > >>> t = type([1, 2, 3]) > > >>> t is list > > True > > >>> t == list > > True > > >>> > > >>> fn = list.index > > >>> fn is list.index > > True > > >>> fn == list.index > > True > > > > The situations where "is" is truly needed are rather esoteric. > > > > >>> class X: > ... def __eq__(self, other): return True > ... > >>> x = X() > >>> x is None > False > >>> x == None > True > >>> type([1, 2, 3]) is x > False > >>> type([1, 2, 3]) == x > True > >>> x is list.index > False > >>> x == list.index > True > > Revisit your assumptions :) > > ChrisA > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/AA6IIC3I2Q7QNI54CMAD2LTYZLTOT57U/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/S7WAKLW5WOTXW2SJAXFDI7QH6PDA6ILE/ Code of Conduct: http://python.org/psf/codeofconduct/
