To be honest this response underscores the problem with pages like this. In Python, strings and numbers are objects, and “is” tells you if they are the same object. You wouldn’t compare strings or numbers in C using a pointer comparison, and you shouldn’t do it in Python either. The fact that it works sometimes in cpython is a coincidence.

It’s interesting to learn about how the interpreter is implemented, but that’s about it.

You should absolutely be using `is` where appropriate. `x is None` is almost always preferable to `x == None`. If you're checking for object identity, use `is`. If equality, use `==`. They're different use cases.

Especially since == can be overwritten, while 'is' can not.

That's right. Any class can define its own __eq__ method.

How is that your response, after reading this article? The is operator checks whether the two items are the same object, which is critical in some circumstances.

How do you check for None?

Or check that two dicts really are the same object, as opposed to two different dict objects that just happen to have the same keys/values?

I'm not sure I've ever had to do that. When is that a need?

My immediate first thought is, optimisation? If you know you’ve been the same object, you could skip e.g. comparison, or change update logic

This kind of micro optimizations don't make much sense in Python. They complicate the code, and you are still 100 times slower than compiled languages.

It really… doesn’t have to complicate. And I disagree that optimising python code is never necessary. Not everybody is writing 100-line one-off glue scripts.

Also, you are somewhat changing the topic from “what is an example of when you might want to is-compare two dicts”, no?

You are correct. I kind of took `is None` for granted as it just feels boilerplate when coding in Python.

Although I have written over a hundred thousand of lines of code in Python over the years; I use Python mostly for dev ops tooling, reporting, monitoring and automation so they don't get super complex and they mostly can lean on procedural programming patterns.

I could imagine complex frameworks needing heavy use of Objects that could lean on the 'is' keyword.

I personally do use "if var is None:", but can't you just use "if var == None"?

‘is’ checks if it the object ids are the same, with None having a unique one. Equals can be tricked.

Here’s a class that is equal to None, and everything else:

    class EqualsEverything:
        def __equals__(self, other: Any) -> bool:
            return True

Thanks, I saw this on SO too.

Just curious: would it ever happen in practice?

every little thing happens in practice... usually unnoticed and buried while refactoring something innocent/ly.

sooner or later the __eq__ method will be redefined for some class, then reworked, and then.. == None might not be what was supposed to be..

or, my favorite, x='a' ; (x,)[0] == x[0] == x .. but are only equal until x changes to something not-1-long-sequence..

I try to avoid statistical programming, preferring determinism, driven by intent. ;)

So, I use "is" since "is" is not a context dependent concept, like equals is. I've seen this once in the wild, and it made sense for its use:

    def __eq__(self, other):
        return bool(self) == bool(other)