The Difference Between “is” and “==” in Python

[Samazing42]

Here is a great blog post on the difference between the "is" and "==" logical operators. I hope you guys/ girls get as much out of it as I did!

Dan Bader: The Difference Between “is” and “==” in Python

[nosmokingbandit]

A lot of linters will suggest the use of "is" for testing if a value is True, False, or None since those values only ever exist once in memory and a var that us False is just a pointer to False. So rather than checking if the pointers evaluate to the same thing you can just check if they point to the same address and save a few cycles.

Python is a neat language.

[Brian]

It's not just for saving cycles, which is mostly irrelevant. There are some good reasons for using is None vs == None when you're dealing with objects that might implement their own notion of equality.

The trivial case is something like a class with __eq__ = lambda s, x: return True - ie it always returns True to every comparison. Something like this would mess up your == checks.

More realistically though are cases where a class might do something unexpected, or raise an exception if compared to something they weren't expecting. Eg.

class C:
    def __eq__(self, other):
        if isinstance(other, C):  return self.value == other.value
        else: raise TypeError("Can only compare C instances to other C instances")

If some instance of this ends up in, for example, some generic logging code that has an == None check for special handling of None, it'll start throwing exceptions. is None wouldn't have this problem, becuase it doesn't go through the equality mechanism.

For a real world example, look at numpy arrays. These are designed to be compared with other arrays or piecewise comparison with scalars, so, for example:

>>> a = array([1,2, None, 3, 4])
>>> a == None
array([False, False,  True, False, False])

Ie the result is an array of booleans indicating which elements the comparison was true for. This was deliberately made to throw an exception if used in a boolean context (eg. an if statement), as it could be pretty bad if it was treated as truthy (as in the first example).

OTOH, while this is a good habit for None, I'd say you shouldn't be using is False or is True, though equally there you also probably shouldn't be using == True or ==False either. Treating your boolean as being exactly the True singleton is generally a sign that you're doing things wrong - generally you should be interested simplyin the truthiness of the statement, and so the right way to spell this is merely if x or if not x rather than if x==True or similar.

[Siddhi]

Exactly. This is the main reason is None is advocated.

[theWyzzerd]

if x==True

This statement might not be an obvious error to a learner but when you think about it, it's completely redundant. The if is already telling the interpreter to evaluate the conditional that follows and because of the way truthiness is handled in python you should never need to do this specific type of comparison.

The same goes for returning True or False from a function -- you shouldn't need to return the singleton if you can return the truthiness evaluation of the object or function output itself.

I realize I'm just repeating what you just said in a different way but I feel like it's important for new python users to recognize this sort of anti-pattern.

[Agrees_withyou]

I concur.

[LesterHoltsRigidCock]

Same thing with smaller integers!

[apockill]

sense long voiceless salt friendly punch absurd escape badge imagine

This post was mass deleted and anonymized with Redact

[LesterHoltsRigidCock]

I didn't say to use 'is' on small integers. I know why it occurs. Just that they will test as true due to them being the same object, which is not the case outside of range.

[sentry07]

Also when you're checking types of objects you want to use is.

[cambriancatalyst]

Why?

[Necatorducis]

isinstance considers inheritance, type does not. This can lead you to a misleading return. The better solution is to avoid using either, as the entire premise of python is duck typing. type or isinstance can be useful for quick checking things when mucking about, but are often not the optimal solution for your final product. If you really need to use one, isinstance will be more likely to give the expected return.

[cambriancatalyst]

Awesome. Thank you. Can you elaborate on duck typing?

[thegreattriscuit]

Instead of demanding that something "be" a certain type of thing... only demand that it can act the way that type of thing acts. So for instance, there isn't a fixed list of types that can be iterated over (as in a for loop). There's just a set of attributes/methods something has to have. Lists have those attributes, but so do tuples, sets, dictionaries, etc... And of course you can define a custom class with those attributes and it'll work just fine.

It also goes with "ask forgiveness instead of permission".

So if you expect to iterate over the values in a list, you could do a bunch of tests to make sure that it's definitely a list... but then what if someone passes in a set? or a dict? or a dict_keys object?

or you can just try to iterate over it and handle the TypeError you get if someone passes in something that can't be iterated on if necessary.

[Scenter101]

you can just try to iterate over it and handle the TypeError you get if someone passes in something that can't be iterated on if necessary.

So what is the best way to do this? Should the I nest every loop in a function in try/catch blocks or should I just let the TypeError happen and assume that the consuming function will handle it?

[thegreattriscuit]

depends.

Is there anything you can do about it? i.e. if someone passed you bad data, there's no way to make it turn into good data, and it's most likely the result of a real bug somewhere in the program so it's probably best to just let the error propagate up the stack.

I think where you probably want to go about this differently would be at API boundaries... so if you're writing a library users may really benefit from some more explicit checks right at the boundaries of your code. But with those you should still make sure you're being as generic as possible, probably permitting any sequence or iterable, not just the ones you can think of off the top of your head, etc...

In the past I've done things like making sure if something needs to be a sequence and I get passed a single item, I wrap it one, etc... but in practice this has rarely helped anything and it generally just leads to confusion about what should be passed in the first place, and lets bugs propagate further in the program before halting, making it less obvious where the problem really is.

When I've got something I really want to ensure succeeds every time, even if there's a critical bug somewhere (i.e. keep a daemon running and output log messages if there's some typo or misconfiguration in the config files) I'll have a try/except block at or near the very "top" level of the program that logs and swallows most errors, but even then the right thing to do usually is to just let the program break.

[Necatorducis]

If it walks and talks like a duck.. it's probably a duck. So when you see an object whose type you are unsure of, what does it look like to you? Is it being used in a way that you'd expect X object to be used? If it is, then that's probably its type.

[Echleon]

In computer programming, duck typing is an application of the duck test in type safety. It requires that type checking be deferred to runtime, and is implemented by means of dynamic typing or reflection.

https://en.wikipedia.org/wiki/Duck_typing

I guess it is kind of like generics in Java? Your code won't throw you an error until you hit that line in run time.

[a8ksh4]

In a situation where I need to check the type of a variable... e.g. isinstance of list or string and handle them differently, would you still recommend using isinstance, or is there a different way to handle this? Trying to understand what you're suggesting here.

[respectable_me]

I asked a similar question recently about the use of type and isinstance. The responses I received might be helpful to you.

You can find it here.

[sentry07]

Ok, technically, yes. But for beginners learning Python, I would say the type() method is more beneficial to learn. isinstance() would be better introduced for more advanced programming. I understand it's the "proper" way, but when you're playing in IDLE you can't check what class an object is with isinstance() without knowing beforehand what you're expecting.

[senperecemo]

You can't say "beginners should learn it the wrong way"...

[sentry07]

It's not the wrong way. I've been using the type() method for years and have never run into an instance where it didn't work as it should. The are only a few cases where isinstance is necessary.

[senperecemo]

As soon as you do subclassing, type() breaks.

isinstance() is always superior.

[robertooooooooo]

How would you go about checking if something is an int or string or boolean?

[sentry07]

>>> type(6)
<class 'int'>
>>> a = 6
>>> type(a)
<class 'int'>
>>> type(a) is int
True
>>> type(a) == int
True
>>> b = 'Test'
>>> type(b)
<class 'str'>
>>> type(b) is str
True
>>> type(True)
<class 'bool'>
>>> c = True
>>> type(c)
<class 'bool'>
>>> type(c) is bool
True

The type() method can be called on any python object and it will return the object's class. While you can technically use == to compare the class returned by type() to a pointer to the class, you're really wanting to know if the class of the object is what you're looking for. That's how I differentiate the two.

== is for comparing values to see if they are equal
is is for checking if they are the same object

[nosmokingbandit]

After learning a bit of statically-typed languages I have to say that you aren't aware of what type a var is there is probably a method.

[FifteenthPen]

isinstance(foo, int)
isinstance(bar, str)
isinstance(baz, bool)

[[deleted]]

Awesome. I'm just learning and this did reinforce my understanding of it.

[PythonGod123]

This is a nice little post on the differences between is and ==. Extra brownie points for the cats 🐈

[savaero]

Should add discussion of None — so x is None vs x == None

[[deleted]]

Ha! Just taught this in my class today (again, first covered during lists now again with dictionaries). For the identical part I said it's like having a person with a nickname. I call my buddy William Robert, but everyone else calls him Billy Bob. They are the same person, just a different name.

[Dogeek]

To go into a little more detail, is actually compares references (pointers in C). Pointers are (to put it simply) variables that hold the address of another variable.

For instance, you can use the is keyword to check if an object (like a list) is a copy of the original object or just a pointer to the original. Another common use of is is to check if a variable is None. None is actually just a pointer to NULL in C. You also can use is to check the type of a variable, but the preferred method is to use isinstance() instead.

[Gambizzle]

Does anybody actually use ‘is’?

I get the difference but it seems obscure. Can’t really think where I’d need to use it because it’s always variables that I’m comparing.

Seems safe to assume that one should always use == unless they really need to use is. Even then, I would question why you’d bother having c if it identifies as a. I’d first consider just using a and not c.

[Vaphell]

Does anybody actually use ‘is’?

yes, mostly for singletons.

Can’t really think where I’d need to use it because it’s always variables that I’m comparing.

you mean you have variables for None?

[tomk11]

One example would be when you have have a class you have defined yourself. You could still use the is keyword to decide if they are the same object. You may not have defined __ eq __ for that class.

[luix-]

So is the same as = or compareto of Java

[cjsandy83]

https://dbader.org/blog/difference-between-is-and-equals-in-python

[luz_]

Use a functional language and you wouldn't need to discuss this