<div dir="ltr"><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">foo = [process(*t) for t in enumerate(some_iterable)]<br>
<br>
<br>
Le list comprehension sono troppo comode e troppo belle per non usarle<br>
per questo tipo di cose. Hanno meno rumore visivo, e' piu' chiaro il loro intento.</blockquote><div><br></div><div>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<br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
in pratica durante la creazione della lista, potrei dover mettere<br>
degli elementi nella posizione n, ma non avere ancora elementi nelle<br>
posizioni minori di n...</blockquote><div><br></div><div>Come fai una list-comprehension a risolvere questo problema? Non puoi specificare l'indice quando la crei.<br><br><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
> La cosa ottimale e' comunque costruire direttamente la lista con una bella<br>
> list comprehension.<br>
><br>
> In questo caso come fai a costruire una lista con il list-comprehension visto che non hai l'ordine degli elementi?<br>
<br>
Non mi e' chiaro che tipo di problema possa essere risolto (anche in maniera subottimale) pre-allocando<br>
una lista di None e non con una list-comprehension salvo uno che "lasci" dei buchi nella lista.</blockquote><br></div><div>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.<br>
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).<br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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,<br>
almeno confrontare con NullObjectPattern se uno proprio vuole fare una cosa del genere), questo caso non mi<br>
viene da considerarlo.</blockquote><br></div><div>Se rileggi la mia risposta puoi trovare questa premessa:<br><br></div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
se sei sicuro che la seconda lista avrà N elementi</blockquote><div><br></div><div>cioè se sei sicuro che quella lista sarà riempita, quindi sfruttata totalmente.<br></div><div>Quindi per questo problema specifico quali sono i problemi che portano la mia soluzione ad essere considerato un anti-pattern?<br>
<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">> Un esempio stupido, se fornisco un'interfaccia 
Array, allora mi aspetto che le implementazioni forniscano un 
inserimento in O(1).<br>
<br>
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.<br>
<br></blockquote></div><div> Errore mio, avrei dovuto usare il termine corretto: assegnamento, quindi un'operazione <span style="font-family:courier new,monospace">v[i] = el</span><br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
><br>
>  - Il concetto di lista di per sè non è limitato ad una struttura che espone una sequenza ordinata di elementi?<br>
><br>
> 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.<br>
<br>
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.</blockquote><div><br></div><div>Avrei dovuto aggiungere anche un metodo set, comunque quelli suggeriti da te si possono derivre da quelli fondamentali elencati da me.<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
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.<br>
<br>
Questo e' proprio uno dei casi in cui la semplice definizione dei tipi 
e' completamente insufficiente per una buona caratterizzazione del 
tutto.<br>
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.<br>
<br>
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</blockquote><div><br></div><div>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).<br>
</div><div>In più condivido che la programmazione ad oggetti sia diventata una moda, in troppi casi violentata e venduta come soluzione ad ogni male.<br></div></div></div></div></div>