isinstance (foo, bar) vs type (foo) is bar
Eine Frage der Semantik.
Wenn ich bis vor kurzem eine Typprüfung an einer Struktur durchführen müsste, würde ich verwendentype(obj) is list
et. al. Seit ich SO beigetreten bin, sind mir jedoch alle aufgefallen (und ich meineJEDERMANN) Verwendetisinstance(obj,list)
stattdessen. Es scheint, dass sie auch und sindtimeit
zeigt fast identische Geschwindigkeit zwischen ihnen.
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
In der Tat sogardis
stimmt zu, sie sind auch, mit Ausnahme vontype is
'sCOMPARE_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
Ich finde es ehrlich gesagt lesbarer zu sagenif type(foo) is list:
alsif isinstance(foo,list):
, der erste ist im Grunde nur Pseudo-Code und der zweite ruft eine Funktion auf (die ich jedes Mal nachschlagen muss, um zu seinisinstance
oderinstanceof
) mit einigen Argumenten. Es sieht nicht aus wie eine Typumwandlung, und es gibt keinen expliziten Weg zu wissen, obisinstance(a,b)
prüft obb
ist eine Instanz vona
oder umgekehrt.
Ich verstehe vondiese Frage dass wir verwendenisinstance
weil es schöner ist über die Vererbung.type(ClassDerivedFromList) is list
wird während scheiternisinstance(ClassDerivedFromList,list)
wird gelingen. Aber wenn ich prüfe, was IMMER EIN BASISOBJEKT sein sollte, was verliere ich dann wirklich daran?type is
?