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

vs

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

Quale dovrebbe essere preferito e perché?

hasattrinternamente e rapidamente esegue lo stesso compito del try/exceptblocco: è uno strumento molto specifico, ottimizzato, one-task e quindi dovrebbe essere preferito, quando applicabile, all'alternativa molto generica.

Eventuali panchine che illustrano la differenza di prestazioni?

timeit è il tuo amico

$ 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

C'è una terza, e spesso migliore, alternativa:

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

Vantaggi:

1. getattrnon ha il cattivo comportamento di deglutizione delle eccezioni indicato da Martin Geiser - nei vecchi Pythons, hasattringoierà persino un KeyboardInterrupt.

2. La ragione normale per cui controlli se l'oggetto ha un attributo è che puoi usare l'attributo, e questo naturalmente porta ad esso.

3. L'attributo viene letto in modo atomico ed è al sicuro da altri thread che cambiano l'oggetto. (Tuttavia, se questa è una delle principali preoccupazioni, potresti prendere in considerazione la possibilità di bloccare l'oggetto prima di accedervi.)

4. È più corto di try/finallye spesso più corto di hasattr.

5. Un except AttributeErrorblocco ampio può catturare diversi AttributeErrorsda quello che ti aspetti, il che può portare a comportamenti confusi.

6. L'accesso a un attributo è più lento rispetto all'accesso a una variabile locale (specialmente se non è un semplice attributo di istanza). (Anche se, ad essere onesti, la microottimizzazione in Python è spesso una commissione da pazzi.)

Una cosa a cui fare attenzione è che se ti interessa il caso in cui obj.attributeè impostato su Nessuno, dovrai utilizzare un valore sentinella diverso.

Lo uso quasi sempre hasattr : è la scelta corretta per la maggior parte dei casi.

Il caso problematico è quando una classe ha la precedenza __getattr__: hasattrsi cattura tutte le eccezioni invece di catturare proprio AttributeErrorcome ci si aspetta. In altre parole, il codice seguente verrà stampato b: Falseanche se sarebbe più appropriato vedere ValueErrorun'eccezione:

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')

L'importante errore è così scomparso. Questo problema è stato risolto in Python 3.2 ( problema 9666 ) dove hasattrora cattura soloAttributeError .

Una soluzione semplice è scrivere una funzione di utilità come questa:

_notset = object()

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

Questo getattraffrontiamo la situazione e può quindi sollevare l'eccezione appropriata.

Direi che dipende dal fatto che la tua funzione possa accettare oggetti senza l'attributo in base alla progettazione , ad esempio se hai due chiamanti alla funzione, uno che fornisce un oggetto con l'attributo e l'altro che fornisce un oggetto senza di esso.

Se l'unico caso in cui otterrai un oggetto senza l'attributo è dovuto a un errore, consiglierei di utilizzare il meccanismo delle eccezioni anche se potrebbe essere più lento, perché credo che sia un design più pulito.

In conclusione: penso che sia un problema di design e leggibilità piuttosto che un problema di efficienza.

Se non avere l'attributo non è una condizione di errore, la variante di gestione delle eccezioni ha un problema: catturerebbe anche AttributeErrors che potrebbero venire internamente quando si accede a obj.attribute (ad esempio perché l'attributo è una proprietà quindi accedendo chiama del codice).

Questo argomento è stato trattato nel discorso EuroPython 2016 Scrivere più velocemente Python di Sebastian Witowski. Ecco una riproduzione della sua diapositiva con il riepilogo delle prestazioni. Usa anche l' aspetto della terminologia prima di saltare in questa discussione, vale la pena menzionarlo qui per taggare quella parola chiave.

Se l'attributo è effettivamente mancante, chiedere perdono sarà più lento che chiedere i permessi. Quindi, come regola pratica, puoi utilizzare la modalità di richiesta di autorizzazione se sai che è molto probabile che l'attributo manchi o altri problemi che puoi prevedere. Altrimenti, se ti aspetti che il codice risulti nella maggior parte delle volte leggibile

3 PERMESSI O PERDONO?

# CASE 1 -- Attribute Exists
class Foo(object):
    hello = 'world'
foo = Foo()

if hasatter(foo, 'hello'):
    foo.hello
## 149ns ##

try:
    foo.hello
except AttributeError:
    pass
## 43.1 ns ##
## 3.5 times faster


# CASE 2 -- Attribute Absent
class Bar(object):
    pass
bar = Bar()

if hasattr(bar, 'hello'):
    bar.hello
## 428 ns ##

try:
    bar.hello
except AttributeError :
    pass
## 536 ns ##
## 25% slower

Se è solo un attributo che stai testando, direi use hasattr. Tuttavia, se stai effettuando diversi accessi ad attributi che possono o non possono esistere, l'utilizzo di un tryblocco potrebbe farti risparmiare un po 'di digitazione.

Suggerirei l'opzione 2. L'opzione 1 ha una condizione di competizione se qualche altro thread aggiunge o rimuove l'attributo.

Anche Python ha un Idiom , che EAFP ( 'più facile chiedere perdono che il permesso') è meglio di LBYL ( 'guardare prima di saltare').

Da un punto di vista pratico, nella maggior parte delle lingue l'uso di un condizionale sarà sempre notevolmente più veloce che gestire un'eccezione.

Se vuoi gestire il caso di un attributo che non esiste da qualche parte al di fuori della funzione corrente, l'eccezione è il modo migliore per procedere. Un indicatore del fatto che potresti voler utilizzare un'eccezione invece di un condizionale è che il condizionale imposta semplicemente un flag e interrompe l'operazione corrente, e qualcos'altro controlla questo flag e agisce in base a quello.

Detto questo, come sottolinea Rax Olgud, la comunicazione con gli altri è un attributo importante del codice, e ciò che vuoi dire dicendo "questa è una situazione eccezionale" piuttosto che "questo è qualcosa che mi aspetto che accada" potrebbe essere più importante .

Il primo.

Più corto è meglio. Le eccezioni dovrebbero essere eccezionali.

Almeno quando dipende solo da cosa sta succedendo nel programma, tralasciando la parte umana della leggibilità, ecc. (Che in realtà è il più delle volte più importante delle prestazioni (almeno in questo caso - con quella durata delle prestazioni), come hanno sottolineato Roee Adler e altri).

Tuttavia, guardandolo da quella prospettiva, diventa quindi una questione di scelta tra

try: getattr(obj, attr)
except: ...

e

try: obj.attr
except: ...

poiché hasattrutilizza solo il primo caso per determinare il risultato. Cibo per la mente ;-)