Mostrare un oggetto

“

What’s in a name? That which we call a rose
by any other name would smell as sweet.

William Shakespeare, Romeo e Giulietta

Alla fine della scorsa lezione ti ho lasciato con un fastidio. Ogni volta che vogliamo mostrare un brano scriviamo a mano la stessa f-string: print(f"{bohemian.titolo} — {bohemian.artista}"). È ripetitivo, è facile sbagliarlo, e soprattutto è strano: l’oggetto sa tutto di sé — titolo, artista, durata — eppure tocca a noi, da fuori, ricostruirgli la frase ogni volta.

E se fosse il brano stesso a sapersi raccontare? Se potessimo scrivere semplicemente print(bohemian) e ottenere una descrizione sensata? Oggi insegniamo all’oggetto a presentarsi da solo. Lo faremo incontrando i primi due metodi speciali di Python — quelli con il doppio trattino basso ai lati, i cosiddetti dunder — di cui in realtà ne hai già usato uno senza farci caso: __init__.

Prerequisiti

• La lezione precedente, Metodi di classe e statici — in particolare attributi e metodi d’istanza, e il fatto che __init__ viene chiamato da Python per te
• f-string per comporre stringhe (f"{variabile}")
• La differenza tra stampare un valore (print) e restituirlo (return) da una funzione
• Liste: sapere cosa succede quando ne stampi una con print

Cosa imparerai in questa lezione

• Cosa sono i metodi speciali (dunder) e perché Python li chiama al posto tuo
• Come dare a un oggetto una descrizione leggibile con __str__, quella che vede l’utente
• Come dare a un oggetto una descrizione non ambigua con __repr__, quella che serve a chi programma
• Perché print(brano) e print([brano]) non chiamano lo stesso metodo (la sorpresa della lista)
• La regola pratica: definisci sempre __repr__, aggiungi __str__ solo quando la versione per l’utente è diversa
• Come far sì che __repr__ somigli a una chiamata del costruttore — e perché è una buona abitudine

Cosa stampa un oggetto «nudo»

Partiamo da un Brano essenziale, senza alcun metodo speciale oltre a __init__. Proviamo a stamparlo direttamente. Prima di premere Run, predici l’output: cosa comparirà?

Ti aspettavi il titolo? E invece esce qualcosa come <__main__.Brano object at 0x...>: il nome della classe e un codice esadecimale che è, in pratica, l’indirizzo dell’oggetto in memoria. Tecnicamente è una risposta — ti dice che tipo è e che è unico — ma a un essere umano non serve a niente. Python non può indovinare quale dei tre dati vuoi vedere, né come comporli: per stamparlo in modo decente, glielo dobbiamo insegnare noi.

__str__: la faccia per l’utente

Quando scrivi print(qualcosa), dietro le quinte Python chiama il metodo speciale __str__ di quell’oggetto e stampa ciò che restituisce. Se non l’hai definito, ripiega su quella rappresentazione tecnica di prima. Definiamolo, allora: deve restituire (non stampare!) una stringa leggibile.

Niente più indirizzi di memoria. E nota la seconda riga: anche dentro una f-string, {bohemian} passa da __str__. Lo stesso vale per str(bohemian). Da ora il brano sa dire chi è, e noi non dobbiamo più ricostruirgli la frase ogni volta: la formattazione vive dentro l’oggetto, in un posto solo. È esattamente la coesione di cui parliamo dalla prima lezione.

Definizioni

Metodo speciale (dunder)

Un è un metodo dal nome circondato da doppio trattino basso (__nome__) che Python chiama automaticamente in situazioni precise: __init__ alla nascita dell’oggetto, __str__ quando lo stampi. Non lo invochi mai per nome a mano (bohemian.__str__() si può, ma non si fa): scrivi print(bohemian) e Python si occupa del resto. Sono i ganci con cui i tuoi oggetti si integrano nel linguaggio.

La sorpresa della lista

Mettiamo i nostri brani in una playlist — una semplice lista — e stampiamola. Abbiamo definito __str__, quindi vedremo i titoli, giusto? Predici l’output prima di eseguire.

Ricompaiono gli indirizzi di memoria — [<__main__.Brano object at 0x...>, ...] — nonostante __str__ sia definito. Cos’è successo? Quando stampi una lista, Python non chiama __str__ sui suoi elementi: chiama l’altro metodo speciale, __repr__. E quello, noi, non l’abbiamo ancora scritto.

Non è un capriccio. C’è un motivo, e ci porta dritti al secondo protagonista della lezione.

__repr__: la faccia per lo sviluppatore

I due metodi rispondono a due domande diverse:

• __str__ risponde a «come mostro questo oggetto a un utente?» → leggibile, discorsivo, anche incompleto.
• __repr__ risponde a «come descrivo questo oggetto a chi programma?» → non ambiguo, preciso, idealmente completo.

Quando in console ispezioni una lista, un dizionario o un oggetto «da solo», sei nei panni dello sviluppatore che vuole capire esattamente cosa ha in mano: per questo Python sceglie __repr__. La convenzione è che __repr__ somigli alla chiamata del costruttore che ricrea l’oggetto. Aggiungiamolo:

Ora la lista mostra qualcosa di utile: [Brano('Bohemian Rhapsody', 'Queen', 354)]. Leggendolo capisci al volo il tipo e tutti i dati, e — colpo di scena — potresti copiarlo, incollarlo nel codice ed eseguirlo per ottenere un brano identico. Questo è il senso di «non ambiguo».

Programmazione

Il !r dentro la f-string

Hai notato {self.titolo!r}? Quel !r dice all’f-string: «non inserire il valore con __str__, usa il suo __repr__». Su una stringa, __repr__ aggiunge gli apici: ecco perché nell’output compare 'Bohemian Rhapsody' con le virgolette e non Bohemian Rhapsody nudo. È proprio ciò che vuoi in un __repr__: la durata (354) è un numero e va senza apici, i testi vanno con gli apici, così la stringa somiglia davvero al codice che scriveresti. Provalo: togli i due !r e guarda come la rappresentazione diventa subito più ambigua.

Il diagramma mostra chi chiama cosa — e quella freccia tratteggiata è la regola più importante della lezione.

Quando ne basta uno

I due metodi non sono obbligatori in coppia. C’è un’asimmetria voluta: se definisci solo __repr__, Python lo usa anche come ripiego quando servirebbe __str__. Il contrario non vale: definire solo __str__ lascia __repr__ con la sua versione tecnica inutile.

print(bury) non trova un __str__ e usa __repr__: ottieni comunque qualcosa di sensato. Da qui la regola pratica.

Clean code

Definisci sempre __repr__, __str__ solo se serve

Per una classe che vale la pena vedere stampata, parti sempre da __repr__: è la rete di sicurezza che salva ogni print, ogni lista, ogni sessione di debugging. Scrivi __str__ in aggiunta solo quando la versione per l’utente è davvero diversa da quella per lo sviluppatore (per esempio: __str__ mostra Bohemian Rhapsody — Queen, mentre __repr__ mostra Brano('Bohemian Rhapsody', 'Queen', 354)). Se le due versioni coinciderebbero, un solo __repr__ ben fatto basta e avanza. E punta a renderlo non ambiguo, idealmente uguale alla chiamata del costruttore: il tuo te-del-futuro alle 23, a caccia di un bug, ti ringrazierà.

Attenzione

return, non print — e dev’essere una stringa

Due errori classici, entrambi silenziosi finché non ti esplodono in mano:

def __str__(self):
    print(f"{self.titolo}")        # ❌ stampa e basta: restituisce None

def __str__(self):
    return self.durata             # ❌ restituisce un int, non una stringa

__str__ e __repr__ devono restituire (return) una stringa. Se al loro posto fai print, il metodo restituisce None e ottieni effetti assurdi; se restituisci un numero, Python solleva un TypeError al momento della stampa. La forma corretta è sempre return f"...".

In pratica, sul nostro player

Mettiamo insieme i pezzi su una mini-playlist, con entrambi i metodi e una distinzione netta tra i due usi. Cambia i dati, aggiungi un brano, e osserva come l’una e l’altra faccia restano coerenti senza che tu debba comporre stringhe a mano da nessuna parte.

Stessa playlist, due letture: una per chi ascolta, una per chi mette le mani nel codice. È la frase di Shakespeare ribaltata in chiave informatica — il nome con cui mostri la rosa cambia a seconda di chi la guarda, ma la rosa (l’oggetto, con i suoi dati) resta la stessa.

Il «modello dati» di Python

__str__ e __repr__ sono solo i primi due di una famiglia numerosa. Python definisce decine di metodi speciali che ti permettono di agganciare i tuoi oggetti alle sintassi del linguaggio: __len__ per far funzionare len(oggetto), __eq__ per il confronto con ==, __add__ per l’operatore +, __iter__ per i cicli for. Questo insieme di ganci si chiama modello dati (data model) e ne incontreremo altri pezzi più avanti, quando insegneremo ai nostri oggetti a essere confrontati, sommati e attraversati. Per ora ti basti sapere che ogni volta che scrivi __qualcosa__, stai parlando direttamente all’interprete.

In a nutshell

• I metodi speciali (dunder, __nome__) sono chiamati da Python in automatico in situazioni precise; __init__ ne è un esempio che già usavi.
• __str__ dà la versione leggibile per l’utente: la usano print(), str() e le f-string. Deve return di una stringa.
• __repr__ dà la versione non ambigua per lo sviluppatore: la usano repr(), la console e gli elementi dentro liste e dizionari. Per convenzione somiglia alla chiamata del costruttore.
• Se manca __str__, Python ripiega su __repr__ (non viceversa): per questo conviene definire sempre __repr__ e aggiungere __str__ solo quando la vista per l’utente è diversa.
• Nelle f-string, {valore!r} forza l’uso di __repr__ (sulle stringhe aggiunge gli apici): comodo proprio dentro __repr__.

Mettiti alla provaDomanda 1 / 3

Hai una classe Brano con __str__ definito ma senza __repr__. Cosa stampa print([brano]) (il brano dentro una lista)?

Scegli la risposta corretta

Per andare oltre

I nostri brani ora si raccontano bene, ma c’è ancora una falla: chiunque, da fuori, può scrivere bohemian.durata = -50 e darci un brano dalla durata negativa. L’oggetto non si difende. La prossima lezione apre il Capitolo II e affronta proprio questo: l’incapsulamento, cioè come un oggetto protegge il proprio stato e decide cosa lasciar toccare e cosa no.

Nel frattempo, un esercizio senza fretta: riprendi la classe Utente immaginata la scorsa lezione. Scrivi il suo __repr__ (che assomigli al costruttore: Utente('mario@...', ...)) e poi chiediti — la versione per l’utente, lo __str__, sarebbe diversa? Un profilo social mostra @mario, mica l’email completa. Se la risposta è sì, hai trovato il caso in cui valgono entrambi i metodi.