I understand that Python itself should work with classes with any sort of
crazy semantics, and I appreciate your spelling it out. We could say that
the bar for the Python implementation is the highest, since who knows what
experimental == someone might cook up playing around, and you would like
the underlying Python layers to hold up correctly no matter what.
Now I chose the lines from the Python modules as just a random source of
PEP8 compliant code, but I think I confused my message there, which was
about "regular" not Python implementation code.
Here is my proposal:
>
> Add the following parenthetical to the mandatory-is rule: (this rule
> is optional for code that is not part of an implementation of Python).
>
So if I have a line like this
if x == None:
and this is in a Python program that is using regular old Python classes
like int and list and dict and whatever. It is not importing a class with
weird == semantics. We would agree, that == is going to work perfectly in
that case. My code is relying on the == of the classes it uses, and that is
sensible.
Or perhaps my proposal should have been "It's permissible to use == in
cases where it works correctly."
Is PEP8 well served to forbid using == in cases where it works perfectly?
Best,
Nick
On Mon, Aug 30, 2021 at 3:42 PM Carl Meyer <c...@oddbird.net> wrote:
> Hi Nick,
>
> On Mon, Aug 30, 2021 at 4:25 PM Nick Parlante <n...@cs.stanford.edu>
> wrote:
> > 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 ==.
>
> If you have `if x == None:`, you don't only have to care about whether
> `None` has an "oddball" definition of ==, you also have to care about
> whether the type of `x` does! Since in many of these cases `x` is
> something passed in from outside the function, you may not have any
> idea about or control over its type. That's why people are telling you
> that almost all the occurrences you've found would in fact be unsafe
> if changed from `is` to `==`, and it's very rare that you can
> "eyeball" a particular case and declare confidently that it would be
> fine to switch it from `is` to `==`.
>
> Carl
>
_______________________________________________
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/MOXN4E4YFARUGLGTPMNMRPFZJQE4TSP2/
Code of Conduct: http://python.org/psf/codeofconduct/
