Perché abbiamo bisogno di tuple in Python (o in qualsiasi tipo di dati immutabile)?

Ho letto diversi tutorial su Python (Dive Into Python, per esempio) e il riferimento linguistico su Python.org - Non vedo perché la lingua abbia bisogno di tuple.

Le tuple non hanno metodi rispetto a un elenco o set, e se devo convertire una tupla in un set o elenco per poterli ordinare, a che serve usare una tupla?

Immutabilità?

Perché a qualcuno importa se una variabile vive in un posto diverso nella memoria rispetto a quando è stata originariamente allocata? Tutta questa faccenda dell'immutabilità in Python sembra essere troppo enfatizzata.

In C / C ++ se allocare un puntatore e punto un po 'di memoria valida, non mi interessa dove si trova l'indirizzo fintanto che non è nullo prima di usarlo.

Ogni volta che faccio riferimento a quella variabile, non ho bisogno di sapere se il puntatore sta ancora puntando all'indirizzo originale o meno. Controllo solo null e lo uso (o no).

In Python, quando allocare una stringa (o tupla) la assegno a x, quindi modifico la stringa, perché mi interessa se è l'oggetto originale? Finché la variabile punta ai miei dati, è tutto ciò che conta.

>>> x='hello'
>>> id(x)
1234567
>>> x='good bye'
>>> id(x)
5432167

x fa ancora riferimento ai dati che desidero, perché qualcuno deve preoccuparsi se il suo ID è uguale o diverso?

1. oggetti immutabili possono consentire una sostanziale ottimizzazione; questo è presumibilmente il motivo per cui le stringhe sono anche immutabili in Java, sviluppate abbastanza separatamente ma all'incirca nello stesso momento di Python, e praticamente tutto è immutabile in linguaggi veramente funzionali.

2. in Python in particolare, solo gli immutabili possono essere hash (e, quindi, membri di insiemi o chiavi nei dizionari). Ancora una volta, questa ottimizzazione economica, ma molto più di un semplice "sostanziale" (la progettazione di tabelle hash decenti che memorizzano oggetti completamente mutabili è un incubo - o prendi copie di tutto non appena lo hai, o l'incubo di verificare se l'hash dell'oggetto è cambiato dall'ultima volta che hai preso un riferimento ad esso alza la sua brutta testa).

Esempio di problema di ottimizzazione:

$ python -mtimeit '["fee", "fie", "fo", "fum"]'
1000000 loops, best of 3: 0.432 usec per loop
$ python -mtimeit '("fee", "fie", "fo", "fum")'
10000000 loops, best of 3: 0.0563 usec per loop

Nessuna delle risposte sopra sottolinea il vero problema delle tuple contro le liste, che molte novità di Python sembrano non comprendere appieno.

Tuple e liste hanno scopi diversi. Gli elenchi memorizzano dati omogenei. Puoi e dovresti avere un elenco come questo:

["Bob", "Joe", "John", "Sam"]

Il motivo che è un uso corretto degli elenchi è perché si tratta di tutti i tipi di dati omogenei, in particolare i nomi delle persone. Ma prendi un elenco come questo:

["Billy", "Bob", "Joe", 42]

Tale elenco è il nome completo di una persona e la sua età. Questo non è un tipo di dati. Il modo corretto di archiviare tali informazioni è in una tupla o in un oggetto. Diciamo che ne abbiamo alcuni:

[("Billy", "Bob", "Joe", 42), ("Robert", "", "Smith", 31)]

L'immutabilità e la mutabilità di Tuples and Lists non è la differenza principale. Un elenco è un elenco dello stesso tipo di elementi: file, nomi, oggetti. Le tuple sono un raggruppamento di diversi tipi di oggetti. Hanno usi diversi e molti programmatori di Python abusano di elenchi per cui sono intese le tuple.

Per favore, no.

Modificare:

Penso che questo post sul blog spieghi perché lo penso meglio di me: http://news.e-scribe.com/397

se devo convertire una tupla in un set o in un elenco per poterli ordinare, a che serve usare una tupla?

In questo caso particolare, probabilmente non ha senso. Questo non è un problema, perché non è uno dei casi in cui potresti prendere in considerazione l'uso di una tupla.

Come fai notare, le tuple sono immutabili. Le ragioni per avere tipi immutabili si applicano alle tuple:

• efficienza di copia: anziché copiare un oggetto immutabile, puoi alias (associare una variabile a un riferimento)
• efficienza di confronto: quando si utilizza la copia per riferimento, è possibile confrontare due variabili confrontando la posizione anziché il contenuto
• interning: è necessario archiviare al massimo una copia di qualsiasi valore immutabile
• non è necessario sincronizzare l'accesso agli oggetti immutabili nel codice simultaneo
• const correttezza: alcuni valori non dovrebbero essere autorizzati a cambiare. Questo (per me) è il motivo principale per i tipi immutabili.

Si noti che una particolare implementazione di Python potrebbe non utilizzare tutte le funzionalità di cui sopra.

Le chiavi del dizionario devono essere immutabili, altrimenti la modifica delle proprietà di un oggetto chiave può invalidare gli invarianti della struttura di dati sottostante. Le tuple possono quindi essere potenzialmente utilizzate come chiavi. Questa è una conseguenza della costante correttezza.

Vedi anche " Presentazione delle tuple ", da Dive Into Python .

A volte ci piace usare gli oggetti come chiavi del dizionario

Per quello che vale, le tuple di recente (2.6+) sono cresciute index()e i count()metodi

Ho sempre trovato che avere due tipi completamente separati per la stessa struttura di dati di base (array) fosse una progettazione scomoda, ma non un vero problema nella pratica. (Ogni lingua ha le sue verruche, incluso Python, ma questa non è importante.)

Perché a qualcuno importa se una variabile vive in un posto diverso nella memoria rispetto a quando è stata originariamente allocata? Tutta questa faccenda dell'immutabilità in Python sembra essere troppo enfatizzata.

Queste sono cose diverse. La mutabilità non è correlata al luogo in cui è memorizzata; significa che le cose a cui punta non possono cambiare.

Gli oggetti Python non possono cambiare posizione dopo essere stati creati, modificabili o meno. (Più precisamente, il valore di id () non può cambiare - stessa cosa, in pratica.) La memoria interna degli oggetti mutabili può cambiare, ma si tratta di un dettaglio di implementazione nascosto.

>>> x='hello'
>>> id(x)
1234567
>>> x='good bye'
>>> id(x)
5432167

Questo non sta modificando ("mutando") la variabile; sta creando una nuova variabile con lo stesso nome e scartando quella vecchia. Confronta con un'operazione di mutazione:

>>> a = [1,2,3]
>>> id(a)
3084599212L
>>> a[1] = 5
>>> a
[1, 5, 3]
>>> id(a)
3084599212L

Come altri hanno sottolineato, ciò consente di utilizzare le matrici come chiavi dei dizionari e altre strutture di dati che richiedono immutabilità.

Nota che le chiavi per i dizionari non devono essere completamente immutabili. Solo la parte utilizzata come chiave deve essere immutabile; per alcuni usi, questa è una distinzione importante. Ad esempio, potresti avere una classe che rappresenta un utente, che confronta l'uguaglianza e un hash con il nome utente univoco. È quindi possibile appendere altri dati mutabili sulla classe: "utente connesso", ecc. Poiché ciò non influisce sull'uguaglianza o sull'hash, è possibile e perfettamente valido utilizzarlo come chiave in un dizionario. Questo non è troppo comunemente necessario in Python; Lo sottolineo solo perché diverse persone hanno affermato che le chiavi devono essere "immutabili", il che è solo parzialmente corretto. Tuttavia, l'ho usato molte volte con mappe e set C ++.

Come Gnibbler ha offerto in un commento, Guido ha espresso un'opinione non pienamente accettata / apprezzata: "gli elenchi sono per dati omogenei, le tuple sono per dati eterogenei". Naturalmente, molti degli oppositori hanno interpretato ciò nel senso che tutti gli elementi di un elenco dovrebbero essere dello stesso tipo.

Mi piace vederlo diversamente, non diversamente dagli altri anche in passato:

blue= 0, 0, 255
alist= ["red", "green", blue]

Nota che considero gli alist come omogenei, anche se type (alist [1])! = Type (alist [2]).

Se posso cambiare l'ordine degli elementi e non avrò problemi nel mio codice (a parte le ipotesi, ad esempio "dovrebbe essere ordinato"), allora dovrebbe essere usato un elenco. In caso contrario (come nella tupla bluesopra), allora dovrei usare una tupla.

Sono importanti poiché garantiscono al chiamante che l'oggetto che passano non sarà mutato. Se lo fai:

a = [1,1,1]
doWork(a)

Il chiamante non ha alcuna garanzia del valore di a dopo la chiamata. Però,

a = (1,1,1)
doWorK(a)

Ora tu come chiamante o come lettore di questo codice sai che a è lo stesso. Potresti sempre per questo scenario creare una copia dell'elenco e passarlo, ma ora stai sprecando cicli invece di usare un costrutto linguistico che ha più senso semantico.

puoi vedere qui per qualche discussione al riguardo

La tua domanda (e i commenti di follow-up) si concentrano sul fatto che l'id () cambi durante un compito. Concentrarsi su questo effetto di follow-on della differenza tra la sostituzione di oggetti immutabili e la modifica di oggetti mutabili piuttosto che la differenza stessa non è forse l'approccio migliore.

Prima di continuare, assicurati che il comportamento dimostrato di seguito sia quello che ti aspetti da Python.

>>> a1 = [1]
>>> a2 = a1
>>> print a2[0]
1
>>> a1[0] = 2
>>> print a2[0]
2

In questo caso, il contenuto di a2 è stato modificato, anche se solo a1 è stato assegnato un nuovo valore. Contrariamente a quanto segue:

>>> a1 = (1,)
>>> a2 = a1
>>> print a2[0]
1
>>> a1 = (2,)
>>> print a2[0]
1

In quest'ultimo caso, abbiamo sostituito l'intero elenco, anziché aggiornarne i contenuti. Con tipi immutabili come le tuple, questo è l'unico comportamento consentito.

Perché è importante? Diciamo che hai un dict:

>>> t1 = (1,2)
>>> d1 = { t1 : 'three' }
>>> print d1
{(1,2): 'three'}
>>> t1[0] = 0  ## results in a TypeError, as tuples cannot be modified
>>> t1 = (2,3) ## creates a new tuple, does not modify the old one
>>> print d1   ## as seen here, the dict is still intact
{(1,2): 'three'}

Usando una tupla, il dizionario è sicuro dal fatto che le sue chiavi cambino "da sotto" ad elementi che hanno un valore diverso. Questo è fondamentale per consentire un'implementazione efficiente.