è veramente necessario per Python distinguere tra tuple, liste, dict, dices e set ordinati?

this being the case, can anyone explain why not?

L'ottimizzatore non può compensare perché l'ottimizzatore funziona in fase di compilazione. Non può sapere come verranno utilizzate le raccolte, quindi non può ottimizzare le raccolte per le operazioni più comuni. Peggio ancora, le operazioni comuni potrebbero non essere le più importanti. Supponiamo di fare 1000 inserti, ma tutti esistono per consentirvi di eseguire una rapida ricerca in un secondo momento. Gli inserti potrebbero non avere importanza perché sono fatti in background mentre la tua app viene caricata. Non c'è modo per l'ottimizzatore di sapere.

would this be a massive performance hit

Come con tutte le cose, dipende. Lascia che provi a fornire una spiegazione rapida e di alto livello perché .

La ragione per cui non può esserci una struttura di dati universale è a causa di compromessi. Se esistesse una struttura che fosse veloce da inserire, veloce da cercare, rapida da cancellare, veloce da ordinare, efficiente in memoria, thread-safe, senza penalizzazioni di ridimensionamento ... beh, sicuramente la useremmo. Il problema è che se si ottimizza una struttura dati per esempio, inserzioni rapide, qualcos'altro ne risentirà. Questa tabella (grazie a questa domanda ) mostra quali sono tutti quei compromessi.

E quei compromessi sono piuttosto significativi. Avere codice fare qualcosa di comune in O(n) (o peggio) piuttosto che O(1) è ciò che prende il tempo di esecuzione della tua app da millisecondi a secondi e da secondi a minuti o ore.

Quindi sì, è necessario avere tutte queste raccolte.

Detto questo, spesso non importa se li usi . Ad esempio, in C # c'è List<T> che è "abbastanza buono" per qualsiasi raccolta di base e Dictionary<K,V> che è "abbastanza buono" quando hai bisogno di una ricerca. Poche applicazioni devono essere altamente performanti, e in quelle app una piccola parte degli account app per la maggior parte del runtime. Usare le collezioni predefinite fino a quando il tuo profiler ti dice in modo diverso è un buon approccio per i principianti, purché tu sappia che esistono le altre collezioni e perché esistono.

Sembra che tu abbia delle nozioni preconcette che provengono da PHP. Non penso che nessun altro linguaggio di uso comune abbia una struttura di dati del tipo "fai-tutto" come gli array di PHP.

Uno degli scopi di più tipi di collezioni è quello di chiarire al lettore a cosa serve la struttura dei dati. Ad esempio, se ti viene assegnato un list , sai che non puoi chiedere a["foo"] . Se ti viene dato un set , sai che non ha senso chiedere il quinto elemento. Se ti viene assegnato un tuple , sai che non ti è possibile che tu possa apportare modifiche ad esso.

Come accennato, ci sono anche considerazioni sulle prestazioni. Sebbene sia possibile costruire un contenitore di dati generico con prestazioni ragionevoli rispetto alla maggior parte dei casi comuni, puoi fare di meglio costruendo strutture dati specializzate.

Queste considerazioni semplificano e chiariscono i processi di (a) costruzione del software in primo luogo e (b) rendendo più facile per i lettori capire lo scopo delle strutture dati. Se tutto fosse un contenitore per scopi generali come "array" PHP, allora è meno chiaro come dovrebbero essere usati i dati.

Infine, si cita una "singola struttura dati di tipo JSON", ma JSON non ha un singolo tipo di dati. I tipi aggregati all'interno di JSON sono array sequenziali identificati con [] e associati nome-valore denotati con {} . Sono già due tipi di dati diversi che non contano i tipi scalari.

Ci sono diversi motivi per cui:

1. Alcuni oggetti sono più leggeri di altri, come citato da Telastyn, le prestazioni diminuiranno. Una tupla, ad esempio, funziona molto più velocemente di un ditt.

2. Gli oggetti si comportano diversamente e questo è intenzionale. Le liste sono accessibili tramite indicizzazione numerata (in pratica sono in ordine cronologico e puoi ottenere l'ennesimo elemento). Sono anche iterabili. Gli insiemi, d'altra parte, non hanno deliberatamente alcun ordine e lo stesso oggetto nell'insieme non può essere ripetuto due volte, come in un insieme, qualsiasi oggetto è dentro o fuori. Le tuple sono principalmente per le prestazioni. Poiché non possono essere modificati, sono "di sola lettura", vengono eseguiti molto più velocemente, quindi è meglio usarli se non si modifica il gruppo dopo la creazione. I dadi sono molto simili alle liste, solo tu assegni la chiave. Questo è parte integrante di Python, ad esempio è necessario in un oggetto. dict . Questi comportamenti sono pensati in modo tale che ci sia un modo semplice per ottenere qualunque tipo di gruppo si desideri, invece di dover cercare di ottenere un singolo tipo di gruppo per comportarsi come si desidera. In questo modo, il codice è più facile da leggere e scrivere.

3. Python è orientato agli oggetti (e gestito), quindi è molto semplice creare una nuova struttura dati. Per questo motivo, non è affatto improbabile che un modo utile per strutturare i dati sia incluso in python. Ad esempio, è molto più semplice aggiungere un nuovo tipo in C.