> foo = [process(*t) for t in enumerate(some_iterable)] > > > Le list comprehension sono troppo comode e troppo belle per non usarle > per questo tipo di cose. Hanno meno rumore visivo, e' piu' chiaro il loro > intento.
Sottoscrivo per la bellezza delle comprehension che uso sempre quando possibile vista la loro efficienza, ma in questo caso non puoi usare visto che non conosci a priori i valori, infatti ti ricordo che la richiesta era la seguente in pratica durante la creazione della lista, potrei dover mettere > degli elementi nella posizione n, ma non avere ancora elementi nelle > posizioni minori di n... Come fai una list-comprehension a risolvere questo problema? Non puoi specificare l'indice quando la crei. > La cosa ottimale e' comunque costruire direttamente la lista con una bella > > list comprehension. > > > > In questo caso come fai a costruire una lista con il list-comprehension > visto che non hai l'ordine degli elementi? > > Non mi e' chiaro che tipo di problema possa essere risolto (anche in > maniera subottimale) pre-allocando > una lista di None e non con una list-comprehension salvo uno che "lasci" > dei buchi nella lista. La preallocazione della lista l'ho suggerita solo perchè si parlava di liste sparse, mi sembrava ovvio, la richiesta era come gestire una lista sparsa, la risposta era per gestire una lista sparsa. Non mi sembra di aver detto che ogni volta che si debba costruire una lista si debba allocare la lista, visto che preferisco di gran lunga le *-comprehension (in quasi caso non utilizzabili, se non per la soluzione con dizionario). Ora siccome trovo un incubo assoluto l'idea di avere una lista con dentro > un po' di None e un po' di oggetti (altro anti-pattern, > almeno confrontare con NullObjectPattern se uno proprio vuole fare una > cosa del genere), questo caso non mi > viene da considerarlo. Se rileggi la mia risposta puoi trovare questa premessa: se sei sicuro che la seconda lista avrà N elementi cioè se sei sicuro che quella lista sarà riempita, quindi sfruttata totalmente. Quindi per questo problema specifico quali sono i problemi che portano la mia soluzione ad essere considerato un anti-pattern? > Un esempio stupido, se fornisco un'interfaccia Array, allora mi aspetto > che le implementazioni forniscano un inserimento in O(1). > > Non conosco nessun array che ti consenta questo. Quello che puoi fare e' > una scrittura in O(1), ma l'inseriemento in un array (salvo che in coda) e' > notoriamente costoso. Ci sono alcune operazioni che ti danno un O(log(n)) > con una base del logaritmo piuttosto grossa, tuttavia. Ma e' robba un po' > esotica. > > Errore mio, avrei dovuto usare il termine corretto: assegnamento, quindi un'operazione v[i] = el > > > - Il concetto di lista di per sè non è limitato ad una struttura che > espone una sequenza ordinata di elementi? > > > > Si, è una struttura che ti permette di inserire, rimuovere e recuperare > elementi in varie posizioni, solitamente i metodi forniti sono size o > length, insert, remove, get. > > Non direi. Cioe' Java ce li mette, ma di per se su una lista hai qualcosa > per creare la vuota, testare se e' vuota, cons, tail, head, magari un > qualche tipo di append. Avrei dovuto aggiungere anche un metodo set, comunque quelli suggeriti da te si possono derivre da quelli fondamentali elencati da me. Diciamo che questa parte di informatica era ben studiata ben prima della > moda della programmazione ad oggetti. Quando ancora si parlava solo di > strutture dati astratti (che erano concetti nati appunto all'interno della > comunita' di algoritmisti) qualche discorso sulla complessità delle > operazioni fondamentali era proprio *parte* della definizione di tipo di > dato astratto. > > Questo e' proprio uno dei casi in cui la semplice definizione dei tipi e' > completamente insufficiente per una buona caratterizzazione del tutto. > Per esempio, la sostituibilita' secondo Liskov non ha veramente un modo > per dire che la complessita' computazionale rende due strutture non > sostituibili. Ora *tecnicamente* nessun formalismo *concreto* consente > questo. Ma vista la pretesa di universalita' della programmazione ad > oggetti trovo piu' seccante la cosa. > > Pero' si, resta il fatto che puoi formalmente documentare la complessita' > algoritmica nell'interfaccia. Ma e' qualcosa di drammaticamente ambiguo. > Per esempio non hai veramente un modo di fare un unit test che controlli la > proprieta'. E' in qualche modo una proprieta' che non e' realmente > esprimibile nel mondo in cui ci si muove Son d'accordo, infatti non potendo controllare tali caratteristiche dell'implementazione la responsabilità ricade sulle competenze dell'implementatore (inoltre questi aspetti sono stati discussi quando cercarono di portare l'Adapter pattern dentro python). In più condivido che la programmazione ad oggetti sia diventata una moda, in troppi casi violentata e venduta come soluzione ad ogni male.
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
