Python isinstance() vs type(): Why a Subclass Check Fails

Select a timestamp to watch that moment on YouTube.

1. 00:00

   Imagine a small animal shelter app. It accepts any Animal object, and Dog is a subclass of Animal. The Dog has the behavior we need, but the shelter's type check rejects it. There is no traceback. The program runs and prints the wrong decision, which can be harder to catch than a crash. Before seeing the code, predict what an exact class check will say about a Dog object. In this video we will reproduce that failure, inspect the class returned by `type()`, and compare it with `isinstance()`. Then we will change the check, run the same cases again, and test a surprising boundary: Python considers a Boolean an integer subclass.

2. 00:41

   That last example prevents us from treating `isinstance()` as a mechanical replacement for every type check. The right expression depends on what values your function promises to accept. The companion PythonLessonLab guide lets you run each snippet and complete a checked practice task. The story is small, but the same mistake appears in systems that accept plugin classes, custom exceptions, or data model subclasses. A base-class-only test may pass today and silently exclude new subclasses tomorrow. The first line reports Dog, the concrete class of this object. The next line is False.

3. 01:22

   The final line therefore says rejected, even though Dog inherits from Animal. Follow the expression from the inside out. `type(pet)` returns the Dog class object. The `is` operator asks whether that exact object is the Animal class object. Dog and Animal are two different classes, so their class objects are not identical. Inheritance does not make them identical; it establishes a relationship between them. This code asks a narrower question than the shelter intended. Adding another if statement or wrapping the test in try and except would not repair the rule. Try replacing the Dog object with `Animal()` and the check passes, which

4. 02:03

   explains how a shallow test can miss the bug. If we introduce a Cat subclass later, the same exact-class gate will reject Cat. It is a silent logic error, so the output we just saw is the important evidence. We now need to ask whether the object belongs to the Animal family rather than whether its concrete class is exactly Animal. The first two lines have not changed. The last line is True because `isinstance(pet, Animal)` accepts an instance of Animal or one of Animal's subclasses. That matches the shelter's rule. Here is a useful mental test: if we add Cat as another Animal subclass next month,

5. 02:43

   should a Cat pass without changing this function? If yes, `isinstance()` expresses the intended class family. Exact type identity is still useful when a contract deliberately requires one concrete type. For example, a strict serializer might only support a built-in value class and reject custom subclasses. Avoid comparing `type(value).__name__` with a string. Class names can change, and unrelated classes can share a name. `isinstance()` also accepts a tuple of candidate classes, such as `isinstance(value, (str, bytes))`, if two unrelated types are valid.

6. 03:23

   That tuple lists allowed classes; it does not convert the input. Type membership is also different from checking whether an object happens to expose an attribute. We choose the predicate from the application's promise, then test a base instance, a subclass instance, and a value outside the family. The base Animal and Dog both pass, while the word dog does not. Spelling an animal's name in a string does not turn the string into an Animal. The shelter's policy is fixed. Now look at the next result: `isinstance(True, int)` is True. Python's bool type is an int subclass. In an order form, the integer one could be a valid ticket quantity, but a checkbox

7. 04:06

   value True should not quietly become one ticket. The exact type check rejects True, yet it also rejects any custom int subclass. If the domain allows integer subclasses but excludes Boolean values, state both requirements: `isinstance(value, int)` and `not isinstance(value, bool)`. The final line is False for True. This is more precise than switching to `type(value) is int` just to handle one special case. We also need to decide whether negative counts are valid. A type test answers what kind of value we received; a range test answers whether that value is allowed.

8. 04:46

   In the next run we will combine those rules in one named predicate and verify every boundary, including text that looks like a number. Zero passes, and our TicketCount subclass passes too. True fails despite belonging to the int family because the domain explicitly excludes Booleans. The negative integer has the right type but fails the range rule. The string looks numeric to a human, but this function does not silently convert it. Python evaluates `and` from left to right and stops at the first false condition, so it never compares the string with zero. Pause and predict what `3.0` and `None` will do. Neither passes the initial int membership test; both return False without a

9. 05:28

   comparison error. In the PythonLessonLab guide, write this function yourself and run the task checker against built-in integers, an int subclass, Booleans, negative values, floats, strings, and None. The rule to remember is not “always use one function.” Use `isinstance()` when the contract includes a class and its subclasses. Use exact type identity only when subclasses are intentionally excluded. Write the contract down and test the nearest counterexample. A successful `Animal()` test alone would never reveal the Dog bug, and a successful count of one would never reveal the Boolean edge.