Risposta.

Il decoratore @property consente di trasformare un metodo in un "attributo virtuale" della classe: appare agli utenti della classe come una normale proprietà, ma è controllato dalla logica di una funzione Python. Inizialmente in Python tutti gli attributi di un'istanza erano accessibili direttamente, ma per supportare l'incapsulamento era necessario un meccanismo per gestire l'accesso ai dati senza modificare l'interfaccia della classe.

Storia:

Nelle versioni iniziali di Python non esisteva un meccanismo esplicito per limitare l'accesso agli attributi. Il problema dell'incapsulamento veniva affrontato attraverso convenzioni (ad esempio, l'uso di un underscore), ma qualsiasi modifica nella logica di memorizzazione/validazione dei valori violava la compatibilità. Con l'introduzione del decoratore @property, è diventato possibile dichiarare un metodo come attributo, fornirlo di un getter, un setter e un deleter, mantenendo l'interfaccia della classe invariata.

Problema:

Quando successivamente è necessario aggiungere logica di validazione o calcolo del valore di un campo, ricostruire l'intera interfaccia è troppo costoso - bisogna cambiare tutti i punti di accesso alla variabile. Inoltre, la visibilità della logica interna del campo non dovrebbe essere rivelata all'esterno della classe. @property consente di "virtualizzare" facilmente l'accesso.

Soluzione:

@property implementa il pattern "getter/setter con protezione dell'interfaccia": è possibile aggiungere proprietà calcolabili o controllare l'impostazione del valore senza modificare il codice del cliente.

Esempio di codice:

class Temperature:
    def __init__(self, celsius):
        self._celsius = celsius

    @property
    def celsius(self):
        return self._celsius

    @celsius.setter
    def celsius(self, value):
        if value < -273.15:
            raise ValueError("Temperatura sotto lo zero assoluto!")
        self._celsius = value

    @property
    def fahrenheit(self):
        return self._celsius * 9 / 5 + 32

# Utilizzo
obj = Temperature(25)
print(obj.celsius)   # 25
print(obj.fahrenheit) # 77.0
obj.celsius = -300   # ValueError

Caratteristiche principali:

Consente l'implementazione di proprietà calcolabili, validate o cache senza modificare l'interfaccia del cliente
Fornisce un'interfaccia per le proprietà (senza parentesi durante l'accesso)
Consente di controllare sia la lettura che la scrittura e la cancellazione del valore

Domande insidiose.

Si può sempre aggiungere una property a qualsiasi campo della classe senza compromettere la retrocompatibilità?

No. Se l'attributo era pubblico e veniva utilizzato come normale variabile, la sostituzione con una property è trasparente. Ma se da qualche parte gli accessi avvenivano tramite __dict__ o venivano eseguiti controlli sul tipo tramite type(obj.attr), potrebbero verificarsi comportamenti inaspettati.

È possibile dichiarare solo un setter senza un getter per una proprietà?

No, è necessario avere un getter (metodo con @property) all'inizio, altrimenti Python non sa a quale proprietà "associare" il setter.

Qual è l'ordine dei decorator @property/@setter/@deleter e perché?

Si scrive sempre prima @property (che crea un oggetto proprietà), poi tramite il nome del metodo – @<name>.setter e @<name>.deleter (che completano la property precedentemente creata).

class A:
    @property
    def value(self):
        ...
    @value.setter
    def value(self, v):
        ...

Errori comuni e anti-pattern

Accesso diretto all'attributo chiuso (ad esempio, self._celsius) al di fuori della classe
Violazione del principio di incapsulamento: logica eccessiva nel getter/setter
Ridefinizione della property negli eredi con conflitto di nomi

Esempio dalla vita reale

Caso negativo

Gli attributi della classe erano pubblici, poi è stata aggiunta una proprietà calcolata tramite property dopo il rilascio dell'API pubblica. Nel vecchio codice, l'accesso all'attributo modifica implicitamente il comportamento o genera un errore.

Vantaggi:

L'utente può non modificare l'accesso all'attributo

Svantaggi:

Possono verificarsi errori inaspettati nel codice se la logica di accesso diventa quella del setter/getter
Bassa compatibilità, se il cliente utilizzava l'accesso diretto a dict

Caso positivo

Sin dalla progettazione, i campi erano definiti come privati (con un underscore) e gli utenti hanno lavorato solo tramite metodi/properties. L'aggiunta di nuova logica nella property in futuro è avvenuta senza modificare l'interfaccia del cliente.