[Python] Dubbio sull'uso delle liste...

[Federico Figus]

> 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.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130623/5499948e/attachment.html>