Re: [Python] Python web messaggi in Post e link a file in differenti directory

[Daniele San Giovanni]

Ci sarebbe ConfigParser che sarebbe ottima perchè permette di impostare il
link al file di configurazione specifico nel momento in cui viene
istanziato l' oggetto.

Il problema è che i file di configurazione contengono una cosa del tipo:

config_charts_daily = [
{
"general" : {
'label' : 'Potenza Attiva',  #Etichetta associata alla
curva
'y_axis_umis': 'W',  #Unità di misura per l'
asse y
},
"csv" : {#Le colonne vengono
numerate a partire da 0
'x_csv_column_number' : 0,   #Numero colonna csv da cui
prelevare i dati da riportare sul grafico (asse x)
'y_csv_column_number' : 3,   #Numero colonna csv da cui
prelevare i dati da riportare sul grafico (asse y)
'y_factor' : 0.01#Fattore moltiplicativo
per l' asse y.
}
}
]

Stamattina ho fatto un po' di ricerche su come poter gestire questa
situazione ma poi ho abbandonato.
Adesso sto mettendo tutto in una classe in modo da selezionare di volta in
volta la configurazione desiderata.
Non è l' ideale ma provvisoriamente si potrebbe utilizzare.
L' eval prendendo le dovute precauzioni può anche essere utilizzato.



Il giorno 07 giugno 2013 12:22, enrico franchi
ha scritto:

> 2013/6/6 Daniele Varrazzo :
>
> > Spiegami la differenza tra import ed eval.
>
> Direi che la questione principale e' che mentre ci vuole
> un'atteggiamento pro-attivo da parte dello sviluppatore per creare un
> problema con import [0][1], con eval basta una disattenzione.
>
> E' chiaro che se ad eval passi solo qualcosa di sanitizzato in varia
> maniera non corri nessun rischio particolare. Il problema e' che
> spesso, vista la potenza di eval, molti appena scopertolo ne abusano.
> Questo non vuole dire ovviamente *non usare eval*.
>
> Credo che la posizione di lisper su eval sia sintomatica: eval c'e' da
> piu' di 50 anni.
> La prima risposta qua mi sembra molto valida:
>
> http://stackoverflow.com/questions/2571401/why-exactly-is-eval-evil
>
> abstract:
> per i principianti: in generale non e' necessario, ci sono metodi piu'
> robusti di fare le stesse cose
> per gli un po' meno principianti: ci sono le macro
> A general important reason to avoid EVAL: it is often used for ugly hacks.
>
> Ora, concretizziamo su Python. Sui principianti (o su quelli che anche
> se principianti non sono), spesso e volentieri ci sono altri modi di
> fare le cose, che sono, a mio avviso, piu' strutturati e puliti.
>
> Ci sono anche casi in cui eval e' semplicemente la strada piu' comoda
> e sensata, senza passare per tre metaclassi e due class-decorator.
> Specie perche' noi non abbiamo le macro. Vedi per esempio
> l'implementazione di Raymond delle namedtuples -- almeno, credo sia di
> Raymond --, che alla fine dei conti chiama exec su uno stringone
> Python. E non mi sognerei di dire che e' insicuro: gli input sono ben
> controllati e comunque e' qualcosa che uso al posto della definizione
> di una classe... dove potrei comunque fare le peggio cose, e' input
> mio, non input utente.
>
> Pero' la regola, nel dubbio, meglio evitare features potenzialmente
> pericolose, a mio avviso sta comunque in piedi.
>
>
> ---
> [0] per esempio prendere una stringa dall'utente, salvarla in un
> modulo e importarla.
> [1] a naso, il caso in cui si usa import per un file di configurazione
> e' il cugino buono di quello la sopra: non e' insicuro nel senso che
> chi scrive la configurazione e' chi esegue il programma, su una
> macchina su cui ha i permessi, etc etc etc. E' anche vero che va
> valutato il rapporto costo/beneficio fra avere un file di
> configurazione turing-completo -- quindi flessibilita' massima -- e il
> fatto che appunto, errori di configurazione sono in generale piu'
> difficili da capire -- perche' il parsing e' fatto da Python, che di
> per se non ha idea della semantica intesa della configurazione, ma sa
> solo eseguire python --.
>
>
> --
> .
> ..: -enrico-
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>



-- 
Daniele San Giovanni
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] py and pyc files

[Marco De Paoli]

Il giorno 07 giugno 2013 15:41, Vittorio Spina
ha scritto:

> Qualcuno sa dirmi nel dettaglio la differenza fra files py e pyc? grazie
>

ogni volta che l'interprete python deve eseguire o importare un file
sorgente py
genera o aggiorna, nel caso non esista, il corrispondente file pyc

Il file pyc contiene le istruzioni bytecode corrispondenti alle istruzioni
sorgente del file py
Il file pyc è un file binario

...comunque se cerchi in google py+pyc+files trovi un sacco di roba...

Marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] py and pyc files

[Marco De Paoli]

Il giorno 07 giugno 2013 15:51, Marco De Paoli  ha
scritto:

>
>
> Il giorno 07 giugno 2013 15:41, Vittorio Spina ha 
> scritto:
>
> Qualcuno sa dirmi nel dettaglio la differenza fra files py e pyc? grazie
>>
>
ecco la documentazione ufficiale per il 2.7

http://docs.python.org/2/tutorial/modules.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] py and pyc files

[Vittorio Spina]

Il 07/06/2013 15:53, Marco De Paoli ha scritto:



Il giorno 07 giugno 2013 15:51, Marco De Paoli > ha scritto:




Il giorno 07 giugno 2013 15:41, Vittorio Spina
mailto:vittorio.sp...@gmail.com>> ha
scritto:

Qualcuno sa dirmi nel dettaglio la differenza fra files py e
pyc? grazie


ecco la documentazione ufficiale per il 2.7

http://docs.python.org/2/tutorial/modules.html


grazie mille,
distribuendo i files pyc, il codice è al sicuro, almeno quello relativo 
ai files pyc oppure è facile ritornare alla forma leggibile?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] py and pyc files

[Marco De Paoli]

Il giorno 07 giugno 2013 15:51, Marco De Paoli  ha
scritto:

>
>
> Il giorno 07 giugno 2013 15:41, Vittorio Spina ha 
> scritto:
>
> Qualcuno sa dirmi nel dettaglio la differenza fra files py e pyc? grazie
>>
>
> ogni volta che l'interprete python deve eseguire o importare un file
> sorgente py
>

rettifica:
Quando lo esegui mi sa di no... :-)


grazie per la segnalazione dalla "regia"!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] py and pyc files

[Riccardo mancuso]

pyc è un bytecode, cioè una traduzione a metà tra il linguaggio binario e
quello testuale.



Il giorno 07 giugno 2013 17:01, Matteo Boscolo
ha scritto:

> Il 07/06/2013 16:46, Daniele Varrazzo ha scritto:
>
>  On Fri, 2013-06-07 at 16:04 +0200, Vittorio Spina wrote:
>>
>>  distribuendo i files pyc, il codice è al sicuro, almeno quello relativo
>>> ai files pyc oppure è facile ritornare alla forma leggibile?
>>>
>> Non è al sicuro. Se ne è parlato un sacco di volte in ML: cerca negli
>> archivi.
>>
>>
>>  Nessun sistema e' sicuro ... :)
>
> diciamo che per un utente medio i pyc sono sicuri, poi se sei su windows
> con py2exe o pyinstaller hai un livello di sicurezza in +
>
> ciao,
> Matteo
>
>
> __**_
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/**mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Python web messaggi in Post e link a file in differenti directory

[Daniele San Giovanni]

Quì ho trovato alcuni esempi interessanti
http://wiki.python.org/moin/ConfigParserShootout c' è solo da capire come
si installano i moduli


Il giorno 07 giugno 2013 15:04, Daniele San Giovanni <
sangiovanni.dani...@gmail.com> ha scritto:

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



-- 
Daniele San Giovanni
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python