current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Join the Stack Overflow Community
Stack Overflow is a community of 6.4 million programmers, just like you, helping each other.
Join them; it only takes a minute:
Sign up
up vote 610 down vote favorite
244

What are the differences between these two code fragments? Which way is considered to be more pythonic?

Using type():

import types

if type(a) is types.DictType:
    do_something()
if type(b) in types.StringTypes:
    do_something_else()

Using isinstance():

if isinstance(a, dict):
    do_something()
if isinstance(b, str) or isinstance(b, unicode):
    do_something_else()

Edit: This seems to be discussed already: link.

share|improve this question
    
Please see this answer: stackoverflow.com/a/33953073/1882064 – arcseldon Nov 27 '15 at 11:38
up vote 676 down vote accepted
+100

To summarize the contents of other (already good!) answers, isinstance caters for inheritance (an instance of a derived class is an instance of a base class, too), while checking for equality of type does not (it demands identity of types and rejects instances of subtypes, AKA subclasses).

Normally, in Python, you want your code to support inheritance, of course (since inheritance is so handy, it would be bad to stop code using yours from using it!), so isinstance is less bad than checking identity of types because it seamlessly supports inheritance.

It's not that isinstance is good, mind you—it's just less bad than checking equality of types. The normal, Pythonic, preferred solution is almost invariably "duck typing": try using the argument as if it was of a certain desired type, do it in a try/except statement catching all exceptions that could arise if the argument was not in fact of that type (or any other type nicely duck-mimicking it;-), and in the except clause, try something else (using the argument "as if" it was of some other type).

basestring is, however, quite a special case—a builtin type that exists only to let you use isinstance (both str and Unicode subclass basestring). Strings are sequences (you could loop over them, index them, slice them, ...), but you generally want to treat them as "scalar" types—it's somewhat incovenient (but a reasonably frequent use case) to treat all kinds of strings (and maybe other scalar types, i.e., ones you can't loop on) one way, all containers (lists, sets, dicts, ...) in another way, and basestring plus isinstance helps you do that—the overall structure of this idiom is something like:

if isinstance(x, basestring)
  return treatasscalar(x)
try:
  return treatasiter(iter(x))
except TypeError:
  return treatasscalar(x)

You could say that basestring is an Abstract Base Class ("ABC")—it offers no concrete functionality to subclasses, but rather exists as a "marker", mainly for use with isinstance. The concept is obviously a growing one in Python, since PEP 3119, which introduces a generalization of it, was accepted and has been implemented starting with Python 2.6 and 3.0.

The PEP makes it clear that, while ABCs can often substitute for duck typing, there is generally no big pressure to do that (see here). ABCs as implemented in recent Python versions do however offer extra goodies: isinstance (and issubclass) can now mean more than just "[an instance of] a derived class" (in particular, any class can be "registered" with an ABC so that it will show as a subclass, and its instances as instances of the ABC); and ABCs can also offer extra convenience to actual subclasses in a very natural way via Template Method design pattern applications (see here and here [[part II]] for more on the TM DP, in general and specifically in Python, independent of ABCs).

For the underlying mechanics of ABC support as offered in Python 2.6, see here; for their 3.1 version, very similar, see here. In both versions, standard library module collections (that's the 3.1 version—for the very similar 2.6 version, see here) offers several useful ABCs.

For the purpose of this answer, the key thing to retain about ABCs (beyond an arguably more natural placement for TM DP functionality, compared to the classic Python alternative of mixin classes such as UserDict.DictMixin) is that they make isinstance (and issubclass) much more attractive and pervasive (in Python 2.6 and going forward) than they used to be (in 2.5 and before), and therefore, by contrast, make checking type equality an even worse practice in recent Python versions than it already used to be.

share|improve this answer
8  
You should mention abstract base classes (ABCs), that allow overriding issubclass and isinstance. See [abc][1]. [1]: docs.python.org/library/abc.html – Andrey Vlasovskikh Oct 11 '09 at 6:55
2  
+1 for admonition against type-checking in the first place. I was going to post something similar, but I actually do something similar in pyparsing when I have a method signature that accepts various argument types - since Python does not permit method overloading, you have to simulate it by taking *args as the arg list, type checking what you get, and then branching to the type-appropriate code. – Paul McGuire Oct 11 '09 at 9:54
2  
@Andrey, added a pretty long overview of ABCs, rather than just a mention (since they're somewhat prone to being misunderstood if viewed only through abbreviated references). – Alex Martelli Oct 11 '09 at 16:15
4  
Sometimes isinstance is necessary and you cannot just use duck typing. An example is when you want to handle a single string or a sequence of strings. If you assume it is a sequence then you will have single character elements. If you assume it is a string then that just won't work. In this case you would have to check isinstance(x, str) and then handle the generic sequence case – Matt Apr 19 '13 at 18:48
2  
Note there is a middle ground between checking isinstance and the hold-your-breath try/except approach, in particular if you don't know what you would do in the 'except' case: Rather than checking isinstance, check the availability of the required methods. If you have "If it walks like a duck and quacks like a duck, it is a duck." then check if 'walk' and 'quack' members exist and are functions. – Lutz Prechelt Sep 16 '14 at 12:16
up vote 156 down vote

Here's why isinstance is better than type:

class Vehicle:
    pass

class Truck(Vehicle):
    pass

in this case, a truck object is a Vehicle, but you'll get this:

isinstance(Vehicle(), Vehicle)  # returns True
type(Vehicle()) == Vehicle      # returns True
isinstance(Truck(), Vehicle)    # returns True
type(Truck()) == Vehicle        # returns False, and this probably won't be what you want.

In other words, isinstance is true for subclasses, too.

Also see: How to compare type of an object in Python?

share|improve this answer
64  
because there's case where you don't want the isInstance behaviour I would argue that there is no "better". They just do something different. – philgo20 Mar 2 '12 at 16:22
1  
+1 for the obvious here, in my limited experience with python there have been plenty of times when type has been more called for than isinstance. Sometimes you want a strict type, not any number of subtypes. – Cory Gross Mar 13 '13 at 4:06
4  
type(Vehicle()) == Vehicle returns False for python2.6.5 /lucid – damon May 29 '13 at 7:05
2  
-1, because "isinstance is better than type" is a misleading comment. it is understood like "type is depreciated, use isinstance instead" at the first glance. for instance, what I wanted was exactly type() checking, but I am misleaded for a short time (and had to debug a little bit) for that reason. anyway, except from that line, your answer is the most clear answer. – ceremcem May 30 '15 at 19:10
1  
An example of this that tripped me up, type(True) == int returns False while isinstance(True,int) returns True, because bool is a subclass of int – Chris_Rands Sep 9 at 11:59
up vote 41 down vote

The latter is preferred, because it will handle subclasses properly. In fact, your example can be written even more easily because isinstance()'s second parameter may be a tuple:

if isinstance(b, (str, unicode)):
    do_something_else()

or, using the basestring abstract class:

if isinstance(b, basestring):
    do_something_else()
share|improve this answer
    
When I tried the first one I got TypeError. It only works with a tuple as second arg, not list. Am I doing it wrong or has it just changed since this answer was posted? – Mathias Nielsen Jul 12 '13 at 23:05
1  
isinstance() only accepts a tuple as a second parameter,@MathiasNielsen – Esparta Palma Oct 28 '13 at 15:53
2  
Love the irony that the second parameter of isinstance() cannot be any instance of an Iterable. – Pieter Ennes Oct 10 '14 at 14:25
up vote 26 down vote

Differences between isinstance() and type() in Python?

Type-checking with 

isinstance(obj, Base)

allows for instances of subclasses and multiple possible bases: 

isinstance(obj, (Base1, Base2))

whereas type-checking with 

type(obj) == Base

only supports the type referenced.

Avoid type-checking - use Polymorphism (duck-typing)

In Python, usually you want to allow any type for your arguments, treat it as expected, and if the object doesn't behave as expected, it will raise an appropriate error. This is known as polymorphism, also known as duck-typing.

def function_of_duck(duck):
    duck.quack()
    duck.swim()

If the code above works, we can presume our argument is a duck. Thus we can pass in other things are actual sub-types of duck:

function_of_duck(mallard)

or that work like a duck:

function_of_duck(object_that_quacks_and_swims_like_a_duck)

and our code still works.

However, there are some cases where it is desirable to explicitly type-check. Perhaps you have sensible things to do with several very different object types. For example, the Pandas Dataframe object can be constructed from dicts or records. In such a case, your code needs to know what type of argument it is getting so that it can properly handle it.

So, to answer the question:

Differences between isinstance() and type() in Python?

Allow me to demonstrate the difference:

type

Say you need to ensure certain behavior if your function gets a certain kind of argument (a common use-case for constructors). If you check for type like this:

def foo(data):
    '''accepts a dict to construct something, string support in future'''
    if type(data) != dict:
        # we're only going to test for dicts for now
        raise ValueError('only dicts are supported for now')

If we try to pass in a dict that is a subclass of dict (as we should be able to, if we're expecting our code to follow the principle of Liskov Substitution, that subtypes can be substituted for types) our code breaks!:

from collections import OrderedDict

foo(OrderedDict([('foo', 'bar'), ('fizz', 'buzz')]))

raises an error!

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in foo
ValueError: argument must be a dict

isinstance

But if we use isinstance, we can support Liskov Substitution!:

def foo(a_dict):
    if not isinstance(a_dict, dict):
        raise ValueError('argument must be a dict')
    return a_dict

foo(OrderedDict([('foo', 'bar'), ('fizz', 'buzz')]))

returns OrderedDict([('foo', 'bar'), ('fizz', 'buzz')])

Abstract Base Classes

In fact, we can do even better. collections provides Abstract Base Classes that enforce minimal protocols for various types. In our case, if we only expect the Mapping protocol, we can do the following, and our code becomes even more flexible:

from collections import Mapping

def foo(a_dict):
    if not isinstance(a_dict, Mapping):
        raise ValueError('argument must be a dict')
    return a_dict

Conclusion

So since we want to support substituting subclasses, in most cases, we want to avoid type-checking with type and prefer type-checking with isinstance - unless you really need to know the precise class of the instance.

share|improve this answer
up vote 7 down vote

According to python documentation here is a statement:

8.15. types — Names for built-in types

Starting in Python 2.2, built-in factory functions such as int() and str() are also names for the corresponding types.

So isinstance() should be preferred over type().

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.