<div dir="ltr">Quì ho trovato alcuni esempi interessanti <a href="http://wiki.python.org/moin/ConfigParserShootout">http://wiki.python.org/moin/ConfigParserShootout</a> c' è solo da capire come si installano i moduli<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">Il giorno 07 giugno 2013 15:04, Daniele San Giovanni <span dir="ltr"><<a href="mailto:sangiovanni.daniele@gmail.com" target="_blank">sangiovanni.daniele@gmail.com</a>></span> ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Ci sarebbe <code>ConfigParser che sarebbe ottima perchè permette di impostare il link al file di configurazione specifico nel momento in cui viene istanziato l' oggetto.<br>
<br></code></div>
<code>Il problema è che i file di configurazione contengono una cosa del tipo:<br><br>config_charts_daily = [ <br> {<br> "general" : { <br> 'label' : 'Potenza Attiva', #Etichetta associata alla curva<br>
'y_axis_umis': 'W', #Unità di misura per l' asse y<br> },<br> "csv" : { #Le colonne vengono numerate a partire da 0<br>
'x_csv_column_number' : 0, #Numero colonna csv da cui prelevare i dati da riportare sul grafico (asse x)<br> 'y_csv_column_number' : 3, #Numero colonna csv da cui prelevare i dati da riportare sul grafico (asse y)<br>
'y_factor' : 0.01 #Fattore moltiplicativo per l' asse y.<br> }<br> } <br> ]<br><br></code></div><code>Stamattina ho fatto un po' di ricerche su come poter gestire questa situazione ma poi ho abbandonato. <br>
</code></div><code>Adesso sto mettendo tutto in una classe in modo da selezionare di volta in volta la configurazione desiderata.<br></code></div><div><code>Non è l' ideale ma provvisoriamente si potrebbe utilizzare.<br>
</code></div><code>L' eval prendendo le dovute precauzioni può anche essere utilizzato. <br> <br></code></div><div class="gmail_extra"><br><br><div class="gmail_quote">Il giorno 07 giugno 2013 12:22, enrico franchi <span dir="ltr"><<a href="mailto:enrico.franchi@gmail.com" target="_blank">enrico.franchi@gmail.com</a>></span> ha scritto:<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2013/6/6 Daniele Varrazzo <<a href="mailto:piro@develer.com" target="_blank">piro@develer.com</a>>:<br>
<div><br>
> Spiegami la differenza tra import ed eval.<br>
<br>
</div>Direi che la questione principale e' che mentre ci vuole<br>
un'atteggiamento pro-attivo da parte dello sviluppatore per creare un<br>
problema con import [0][1], con eval basta una disattenzione.<br>
<br>
E' chiaro che se ad eval passi solo qualcosa di sanitizzato in varia<br>
maniera non corri nessun rischio particolare. Il problema e' che<br>
spesso, vista la potenza di eval, molti appena scopertolo ne abusano.<br>
Questo non vuole dire ovviamente *non usare eval*.<br>
<br>
Credo che la posizione di lisper su eval sia sintomatica: eval c'e' da<br>
piu' di 50 anni.<br>
La prima risposta qua mi sembra molto valida:<br>
<br>
<a href="http://stackoverflow.com/questions/2571401/why-exactly-is-eval-evil" target="_blank">http://stackoverflow.com/questions/2571401/why-exactly-is-eval-evil</a><br>
<br>
abstract:<br>
per i principianti: in generale non e' necessario, ci sono metodi piu'<br>
robusti di fare le stesse cose<br>
per gli un po' meno principianti: ci sono le macro<br>
A general important reason to avoid EVAL: it is often used for ugly hacks.<br>
<br>
Ora, concretizziamo su Python. Sui principianti (o su quelli che anche<br>
se principianti non sono), spesso e volentieri ci sono altri modi di<br>
fare le cose, che sono, a mio avviso, piu' strutturati e puliti.<br>
<br>
Ci sono anche casi in cui eval e' semplicemente la strada piu' comoda<br>
e sensata, senza passare per tre metaclassi e due class-decorator.<br>
Specie perche' noi non abbiamo le macro. Vedi per esempio<br>
l'implementazione di Raymond delle namedtuples -- almeno, credo sia di<br>
Raymond --, che alla fine dei conti chiama exec su uno stringone<br>
Python. E non mi sognerei di dire che e' insicuro: gli input sono ben<br>
controllati e comunque e' qualcosa che uso al posto della definizione<br>
di una classe... dove potrei comunque fare le peggio cose, e' input<br>
mio, non input utente.<br>
<br>
Pero' la regola, nel dubbio, meglio evitare features potenzialmente<br>
pericolose, a mio avviso sta comunque in piedi.<br>
<br>
<br>
---<br>
[0] per esempio prendere una stringa dall'utente, salvarla in un<br>
modulo e importarla.<br>
[1] a naso, il caso in cui si usa import per un file di configurazione<br>
e' il cugino buono di quello la sopra: non e' insicuro nel senso che<br>
chi scrive la configurazione e' chi esegue il programma, su una<br>
macchina su cui ha i permessi, etc etc etc. E' anche vero che va<br>
valutato il rapporto costo/beneficio fra avere un file di<br>
configurazione turing-completo -- quindi flessibilita' massima -- e il<br>
fatto che appunto, errori di configurazione sono in generale piu'<br>
difficili da capire -- perche' il parsing e' fatto da Python, che di<br>
per se non ha idea della semantica intesa della configurazione, ma sa<br>
solo eseguire python --.<br>
<br>
<br>
--<br>
.<br>
<span><font color="#888888">..: -enrico-<br>
</font></span><div><div>_______________________________________________<br>
Python mailing list<br>
<a href="mailto:Python@lists.python.it" target="_blank">Python@lists.python.it</a><br>
<a href="http://lists.python.it/mailman/listinfo/python" target="_blank">http://lists.python.it/mailman/listinfo/python</a><br>
</div></div></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br>Daniele San Giovanni
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br>Daniele San Giovanni
</div>