[Python] Il dilemma degli array mutabili

[enrico franchi]

2013/9/18 Piergiuliano Bossi <pgbossi a gmail.com>

In Python le liste sono mutabili e c'e' ben poco che si possa fare senza
> mutarle manipolandole,
>

Prendine atto. E' un dato di fatto. Python ha liste mutabili. Ogni volta
che ho usato un linguaggio con liste mutabili (Python, Lisp) ho desiderato
avere liste immutabili. Ogni volta che ho usato un linguaggio con liste
immutabili, avrei voluto avere liste mutabili.

Semplicemente ci sono classi di problemi che si risolvono meglio con una
struttura dati mutabile e altri con una immutabile. In alcuni casi scrivere
funzionale e' semplicemente una cosa vincente, in altri casi ha un costo
sulle performance tendenzialmente fastidioso.


> per cui in un metodo che riceve una lista in ingresso mi sono trovato
> spesso a copiarle in una variabile locale prima di lavorarci sopra:
>

Questo e' semplicemente un problema tipico della programmazione ad oggetti
classica (ovvero escludendo linguaggi ad oggetti che lavorano
principalmente con oggetti immutabili). E lo risolvi esattamente negli
stessi modi. Tipicamente non vuoi azione a distanza.

Ovvero, in quei casi in cui sei ragionevolmente sicuro che la lista che ti
viene passata non mantenga reference al di fuori del tuo mondo, puoi anche
non copiarla. In quei casi in cui invece hai timore che succeda, la devi
copiare. Ma lo stesso faresti con qualunque oggetto mutabile che non abbia
un'identita' personale.

Poi figurati, ti capisco. Vorrei *tanto* avere liste immutabili. Ah, uno di
questi giorni...

Usare un array.array non cambia le cose di fatto, introducendo tutta
> un'altra categoria di limitazioni.
>

Array serve per cose ben precise. Salva la vita, a volte, ma non e questo
il caso.

Le tuple sono immutabili, ma non funzionano nel senso che ho spiegato sopra
> (si', lo so, per la append potrei creare una nuova tupla e passarle in
> ingresso una lista concatenata della vecchia tupla e del nuovo elemento, ma
> non mi sembra il modo in cui il BDFL le ha intese).
>

Ottima intuizione. Non lo e'.


> Per cui la mia domanda e', quando volete manipolare strutture tipo array
> senza mutarle o mutandole in copia:
> 1) le copiate all'inizio come dicevo sopra
>

Esatto.


> 2) non usate liste, ma tuple, ma poi come compensate la mancanza di append
> e remove (sembra una contraddizione in termini ma non lo e', basterebbe che
> append e remove ritornino nuove strutture dati, copie dell'originale)
>

No no no no! :)



 Aggiungo, io normalmente *non* uso [:].

def __init__(self, people):
    self.people = list(people)

Il motivo? Voglio avere controllo sulla struttura dati dentro la mia
classe. E' mia responsabilita' e la voglio gestire io.
Se voglio un set, faro' set(people), se voglio una lista faro' cosi'.

In teoria il mio chiamante mi puo' legittimamente passare quello che gli
pare, a patto che io possa costruirci una lista.
Non voglio pero' essere limitato dalla semantica che lui ha scelto per la
struttura dati che stava usando. Sia perche' potrebbe non implementare
l'interfaccia che mi serve (e in questo caso sarebbe, diciamo, un errore
suo), sia perche' e' proprio una sequenza diversa da una lista.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130918/7558e371/attachment.html>