hasattr() vs. try-except-Block zur Behandlung nicht vorhandener Attribute

Question

if hasattr(obj, 'attribute'):
    # do somthing

gegen

try:
    # access obj.attribute
except AttributeError, e:
    # deal with AttributeError

Welche sollte bevorzugt werden und warum?

Answer 1

Gibt es Bänke, die den Leistungsunterschied verdeutlichen?

timeit ist dein Freund

$ python -mtimeit -s 'class C(object): a = 4
c = C()' 'hasattr(c, "nonexistent")'
1000000 loops, best of 3: 1.87 usec per loop
$ python -mtimeit -s 'class C(object): a = 4
c = C()' 'hasattr(c, "a")'
1000000 loops, best of 3: 0.446 usec per loop
$ python -mtimeit -s 'class C(object): a = 4
c = C()' 'try:
 c.a
except:
 pass'
1000000 loops, best of 3: 0.247 usec per loop
$ python -mtimeit -s 'class C(object): a = 4
c = C()' 'try:
 c.nonexistent
except:
 pass'
100000 loops, best of 3: 3.13 usec per loop
$

       |positive|negative
hasattr|  0.446 |  1.87 
try    |  0.247 |  3.13

Answer 2

hasattr intern und führt schnell die gleiche Aufgabe aus wie der try/except Block: Es handelt sich um ein sehr spezifisches, optimiertes Werkzeug für eine einzige Aufgabe und sollte daher, wenn möglich, der sehr universellen Alternative vorgezogen werden.

Answer 3

Es gibt eine dritte und oft bessere Alternative:

attr = getattr(obj, 'attribute', None)
if attr is not None:
     print attr

Vorteile:

1. getattr hat nicht die schlechte das von Martin Geiser aufgezeigte Verhalten beim Schlucken von Ausnahmen - in alten Pythons, hasattr verschluckt sogar eine KeyboardInterrupt .

2. Der normale Grund, warum Sie prüfen, ob das Objekt ein Attribut hat, ist, dass Sie das Attribut verwenden können, und das führt natürlich dazu.

3. Das Attribut wird atomar ausgelesen und ist vor anderen Threads, die das Objekt verändern, sicher. (Wenn dies jedoch ein wichtiges Anliegen ist, sollten Sie erwägen, das Objekt zu sperren, bevor Sie darauf zugreifen).

4. Es ist kürzer als try/finally und oft kürzer als hasattr .

5. Eine breite except AttributeError Block kann andere AttributeErrors als der, den Sie erwarten, was zu verwirrendem Verhalten führen kann.

6. Der Zugriff auf ein Attribut ist langsamer als der Zugriff auf eine lokale Variable (insbesondere wenn es sich nicht um ein einfaches Instanzattribut handelt). (Obwohl, um ehrlich zu sein, Mikro-Optimierung in Python ist oft ein Narr's Errand).

Eine Sache, auf die Sie achten sollten, ist, wenn Sie sich für den Fall interessieren, dass obj.attribute auf None gesetzt ist, müssen Sie einen anderen Sentinel-Wert verwenden.

Answer 4

Ich verwende fast immer hasattr : In den meisten Fällen ist es die richtige Wahl.

Problematisch ist der Fall, dass eine Klasse die __getattr__ : hasattr wird alle Ausnahmen auffangen statt nur zu fangen AttributeError wie Sie es erwarten. Mit anderen Worten, der folgende Code druckt b: False auch wenn es angemessener wäre, eine ValueError Ausnahme:

class X(object):
    def __getattr__(self, attr):
        if attr == 'a':
            return 123
        if attr == 'b':
            raise ValueError('important error from your database')
        raise AttributeError

x = X()
print 'a:', hasattr(x, 'a')
print 'b:', hasattr(x, 'b')
print 'c:', hasattr(x, 'c')

Der wichtige Fehler ist damit verschwunden. Dies war behoben in Python 3.2 ( Ausgabe9666 ) wobei hasattr fängt jetzt nur noch AttributeError .

Eine einfache Abhilfe besteht darin, eine Dienstprogrammfunktion wie die folgende zu schreiben:

_notset = object()

def safehasattr(thing, attr):
    return getattr(thing, attr, _notset) is not _notset

Das lässt getattr mit der Situation umgehen und kann dann die entsprechende Ausnahme auslösen.

Answer 5

Ich würde sagen, es hängt davon ab, ob Ihre Funktion Objekte ohne das Attribut akzeptieren kann konstruktionsbedingt z.B. wenn Sie zwei Aufrufer der Funktion haben, von denen einer ein Objekt mit dem Attribut und der andere ein Objekt ohne dieses Attribut liefert.

Wenn der einzige Fall, in dem Sie ein Objekt ohne das Attribut erhalten, auf einen Fehler zurückzuführen ist, würde ich empfehlen, den Ausnahmemechanismus zu verwenden, auch wenn er langsamer sein kann, weil ich glaube, dass es ein saubereres Design ist.

Unterm Strich: Ich denke, es ist eher ein Problem des Designs und der Lesbarkeit als ein Problem der Effizienz.