isinstance(foo,bar) vs type(foo) is bar
Question:
A question of semantics, really.
Up until recently, if I had to do any typechecking on a structure, I would use type(obj) is list et. al. However since joining SO I’ve noticed everyone (and I mean EVERYONE) uses isinstance(obj,list) instead. It seems they are synonymous, and timeit reveals almost IDENTICAL speed between them.
def a(): return type(list()) is list
def b(): return isinstance(list(),list)
from timeit import timeit
timeit(a)
# 0.5239454597495582
timeit(b)
# 0.5021292075273176
Indeed even dis agrees they’re synonymous, with the exception of type is‘s COMPARE_OP
from dis import dis
dis(a)
# 2 0 LOAD_GLOBAL 0 (type)
# 3 LOAD_GLOBAL 1 (list)
# 6 CALL_FUNCTION 0 (0 positional, 0 keyword pair)
# 9 CALL_FUNCTION 1 (1 positional, 0 keyword pair)
# 12 LOAD_GLOBAL 1 (list)
# 15 COMPARE_OP 8 (is)
# 18 RETURN_VALUE
dis(b)
# 2 0 LOAD_GLOBAL 0 (isinstance)
# 3 LOAD_GLOBAL 1 (list)
# 6 CALL_FUNCTION 0 (0 positional, 0 keyword pair)
# 9 LOAD_GLOBAL 1 (list)
# 12 CALL_FUNCTION 2 (2 positional, 0 keyword pair)
# 15 RETURN_VALUE
I frankly find it more readable to say if type(foo) is list: than if isinstance(foo,list):, the first is basically just pseudo-code and the second calls some function (which I have to look up every time to be isinstance or instanceof) with some arguments. It doesn’t look like a type cast, and there’s no explicit way of knowing whether isinstance(a,b) is checking if b is an instance of a or vice-versa.
I understand from this question that we use isinstance because it’s nicer about inheritance. type(ClassDerivedFromList) is list will fail while isinstance(ClassDerivedFromList,list) will succeed. But if I’m checking what should ALWAYS BE A BASE OBJECT, what do I really lose from doing type is?
Answers:
if I’m checking what should ALWAYS BE A BASE OBJECT, what do I really lose from doing type is?
well, it’s nice you give the full documented answer in your question, so your answer is you lose nothing! The only times where isinstance() is necessary is when checking inheritance of a given class compared to another, as you well said and referenced. type() shall be only used to check whether an instance is exactly of a given base type.
Other than the inheritance issue, you also lose the ability to test multiple types when using isinstance. For example:
def chk(typ):
if not isinstance(typ, (str, int)):
raise ValueError('typ must be string or int')
...
The answer to your question is:
No, given that you’re checking for a definite base class, as you loose the ability to test for inherited classes.
And IMO isinstance is nicer to read and in Python: Readability counts.
PS: I’m getting a significant difference in timings (on Python 3.3)
type: 0.5241982917936874
isinstance: 0.46066255811928847
The Python Docs for the built-in type function provide clear guidance on the difference between type (with one arg) and isinstance.
With one argument, return the type of an object. The return value is a type object and generally the same object as returned by object.class.
The isinstance() built-in function is recommended for testing the type of an object, because it takes subclasses into account.
To illustrate, take a look at the inheritance hierarchy below in module diamond:
Then take a look at the python console output below based on module diamond:
As per the documentation, it is more versatile and can cover a wider range of scenarios. With respect to the OP’s original question – the performance characteristics were not stated as a valid reason to favour one over the other. Neither was readability.
For a more in-depth discussion, which includes an explanation on (in the words of the answerer) “why checking type equality is an even worse practice in recent Python versions than it already used to be”, please see this highly voted answer
type(x) doesn’t work with mypy
At least for me, the main reason for preferring isinstance over type(x) is because mypy can infer types from isinstance checks but it can’t with type(x). From the docs:
Mypy can usually infer the types correctly when using isinstance type
tests, but for other kinds of checks you may need to add an explicit
type cast:
def f(o: object) -> None:
if type(o) is int:
o = cast(int, o)
g(o + 1) # This would be an error without the cast
...
else:
...
Source: https://mypy.readthedocs.io/en/stable/common_issues.html?highlight=isinstance#complex-type-tests
A question of semantics, really.
Up until recently, if I had to do any typechecking on a structure, I would use type(obj) is list et. al. However since joining SO I’ve noticed everyone (and I mean EVERYONE) uses isinstance(obj,list) instead. It seems they are synonymous, and timeit reveals almost IDENTICAL speed between them.
def a(): return type(list()) is list
def b(): return isinstance(list(),list)
from timeit import timeit
timeit(a)
# 0.5239454597495582
timeit(b)
# 0.5021292075273176
Indeed even dis agrees they’re synonymous, with the exception of type is‘s COMPARE_OP
from dis import dis
dis(a)
# 2 0 LOAD_GLOBAL 0 (type)
# 3 LOAD_GLOBAL 1 (list)
# 6 CALL_FUNCTION 0 (0 positional, 0 keyword pair)
# 9 CALL_FUNCTION 1 (1 positional, 0 keyword pair)
# 12 LOAD_GLOBAL 1 (list)
# 15 COMPARE_OP 8 (is)
# 18 RETURN_VALUE
dis(b)
# 2 0 LOAD_GLOBAL 0 (isinstance)
# 3 LOAD_GLOBAL 1 (list)
# 6 CALL_FUNCTION 0 (0 positional, 0 keyword pair)
# 9 LOAD_GLOBAL 1 (list)
# 12 CALL_FUNCTION 2 (2 positional, 0 keyword pair)
# 15 RETURN_VALUE
I frankly find it more readable to say if type(foo) is list: than if isinstance(foo,list):, the first is basically just pseudo-code and the second calls some function (which I have to look up every time to be isinstance or instanceof) with some arguments. It doesn’t look like a type cast, and there’s no explicit way of knowing whether isinstance(a,b) is checking if b is an instance of a or vice-versa.
I understand from this question that we use isinstance because it’s nicer about inheritance. type(ClassDerivedFromList) is list will fail while isinstance(ClassDerivedFromList,list) will succeed. But if I’m checking what should ALWAYS BE A BASE OBJECT, what do I really lose from doing type is?
if I’m checking what should ALWAYS BE A BASE OBJECT, what do I really lose from doing type is?
well, it’s nice you give the full documented answer in your question, so your answer is you lose nothing! The only times where isinstance() is necessary is when checking inheritance of a given class compared to another, as you well said and referenced. type() shall be only used to check whether an instance is exactly of a given base type.
Other than the inheritance issue, you also lose the ability to test multiple types when using isinstance. For example:
def chk(typ):
if not isinstance(typ, (str, int)):
raise ValueError('typ must be string or int')
...
The answer to your question is:
No, given that you’re checking for a definite base class, as you loose the ability to test for inherited classes.
And IMO isinstance is nicer to read and in Python: Readability counts.
PS: I’m getting a significant difference in timings (on Python 3.3)
type: 0.5241982917936874
isinstance: 0.46066255811928847
The Python Docs for the built-in type function provide clear guidance on the difference between type (with one arg) and isinstance.
With one argument, return the type of an object. The return value is a type object and generally the same object as returned by object.class.
The isinstance() built-in function is recommended for testing the type of an object, because it takes subclasses into account.
To illustrate, take a look at the inheritance hierarchy below in module diamond:
Then take a look at the python console output below based on module diamond:
As per the documentation, it is more versatile and can cover a wider range of scenarios. With respect to the OP’s original question – the performance characteristics were not stated as a valid reason to favour one over the other. Neither was readability.
For a more in-depth discussion, which includes an explanation on (in the words of the answerer) “why checking type equality is an even worse practice in recent Python versions than it already used to be”, please see this highly voted answer
type(x) doesn’t work with mypy
At least for me, the main reason for preferring isinstance over type(x) is because mypy can infer types from isinstance checks but it can’t with type(x). From the docs:
Mypy can usually infer the types correctly when using isinstance type
tests, but for other kinds of checks you may need to add an explicit
type cast:
def f(o: object) -> None:
if type(o) is int:
o = cast(int, o)
g(o + 1) # This would be an error without the cast
...
else:
...
Source: https://mypy.readthedocs.io/en/stable/common_issues.html?highlight=isinstance#complex-type-tests