Hi Chris - well maybe we're looking at different questions. Your examples
show it is possible to construct a data type where == None does not work.
Clearly that is possible.
1. One conclusion is that the possibility of such == means that in general
the == None form is unreliable. This is the proper mindset of the Python
implementation, where the classes that need to work are practically
unlimited, so relying on == would be unreliable as shown.
2. However, I am interested in the mass of ordinary looking programs that
use strings, lists, ints, dicts, tuples, functions etc. to solve some
problem. It's extremely likely that all of the classes in such a program
have a reasonable definitions of ==. So if the programmer knows that, they
can use the "== None" form in complete confidence. It works perfectly.
It's possible to treat (1) as kind definitive, like that possibility ends
the argument. I agree (1) is true, but do not find it convincing about the
(2) case. I think (2) is more useful for thinking about Python programs in
the world.
Best,
Nick
On Tue, Aug 31, 2021 at 1:31 PM Chris Angelico
On Wed, Sep 1, 2021 at 6:06 AM Nick Parlante
wrote: Is there anyone other than me who would like to push for "== None tolerant" carve out for non-Python-implementation code?
What you're asking is: Is there anyone other than you who would prefer for Python to officially encourage people to write buggy and unreliable code?
No.
I'm done discussing this; if you still genuinely think that "== None" is actually better than "is None", despite all the demonstrations posted, there's no convincing you.
ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/KE4C6L... Code of Conduct: http://python.org/psf/codeofconduct/