Cosa significano i backtick per l'interprete Python: `num`

Sto giocando con la comprensione degli elenchi e mi sono imbattuto in questo piccolo frammento su un altro sito:

return ''.join([`num` for num in xrange(loop_count)])

Ho passato alcuni minuti a provare a replicare la funzione (digitando) prima di rendermi conto che il `num`bit la stava interrompendo.

Cosa fa racchiudere una dichiarazione in quei caratteri? Da quello che posso vedere è l'equivalente di str (num). Ma quando l'ho cronometrato:

return ''.join([str(num) for num in xrange(10000000)])

Ci vogliono 4.09s mentre:

return ''.join([`num` for num in xrange(10000000)])

impiega 2,43 secondi.

Entrambi danno risultati identici ma uno è molto più lento. Che cosa sta succedendo qui?

EDIT: Stranamente ... repr()dà risultati leggermente più lenti di `num`. 2,99 contro 2,43. Utilizzo di Python 2.6 (non ho ancora provato 3.0).

I backtick sono un alias deprecato per repr(). Non usarli più, la sintassi è stata rimossa in Python 3.0.

L'uso dei backtick sembra essere più veloce rispetto all'utilizzo repr(num)o num.__repr__()nella versione 2.x. Immagino sia perché è necessaria una ricerca aggiuntiva nel dizionario nello spazio dei nomi globale (per repr) o nello spazio dei nomi dell'oggetto (per __repr__), rispettivamente.

L'utilizzo del dismodulo dimostra la mia ipotesi:

def f1(a):
    return repr(a)

def f2(a):
    return a.__repr__()

def f3(a):
    return `a`

Spettacoli di smontaggio:

>>> import dis
>>> dis.dis(f1)
  3           0 LOAD_GLOBAL              0 (repr)
              3 LOAD_FAST                0 (a)
              6 CALL_FUNCTION            1
              9 RETURN_VALUE
>>> dis.dis(f2)
  6           0 LOAD_FAST                0 (a)
              3 LOAD_ATTR                0 (__repr__)
              6 CALL_FUNCTION            0
              9 RETURN_VALUE        
>>> dis.dis(f3)
  9           0 LOAD_FAST                0 (a)
              3 UNARY_CONVERT       
              4 RETURN_VALUE   

f1implica una ricerca globale di repr, f2una ricerca di attributi __repr__, mentre l'operatore di backtick è implementato in un codice operativo separato. Poiché non vi è alcun sovraccarico per la ricerca nel dizionario ( LOAD_GLOBAL/ LOAD_ATTR) né per le chiamate di funzione ( CALL_FUNCTION), i backtick sono più veloci.

Immagino che la gente di Python abbia deciso che repr()non vale la pena avere un'operazione separata di basso livello per , e avere entrambi repr()e backtick viola il principio

"Ci dovrebbe essere uno - e preferibilmente solo uno - modo ovvio per farlo"

quindi la funzionalità è stata rimossa in Python 3.0.

La citazione di backtick è generalmente non utile e scomparsa in Python 3.

Per quello che vale, questo:

''.join(map(repr, xrange(10000000)))

è leggermente più veloce della versione backtick per me. Ma preoccuparsi di questo è probabilmente un'ottimizzazione prematura.

La mia ipotesi è che numnon definisce il metodo __str__(), quindi str()deve fare una seconda ricerca per __repr__.

I backtick cercano direttamente __repr__. Se questo è vero, l'uso al repr()posto dei backtick dovrebbe darti gli stessi risultati.