Re: [Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

Ho realizzato e testato anche la classe Storage che sfrutta i cookie,
serializza i dati, crea un hash con base64 e lo invia al client. Alla
ricezione prova a ripristinare i dati, se questi sono corrotti (qualcosa và
storto) allora la sessione viene reinizializzata da capo perdendo tutti i
dati.
Non sò se è opportuno sfruttare un algoritmo a chiave simmetrica,
onestamente vorrei provare AES ma di valide implementazioni per Python3.x
non ne ho trovate (in questo modo sarebbe sfruttabile la chiave "secret"
definita nel file di configurazione).
In questi giorni prevedo di continuare con il Model, se qualcuno ha voglia
di fare qualche esperimento, alcuni esempi ci sono già, potete anche provare
a scrivere i vostri e sviluppare delle semplici applicazioni.

Per non creare disturbo a tutta la lista per errori, segnalazioni,
suggerimenti e quant'altro potete tranquillamente usare il bugtracker su
googlecode [1] oppure unirvi alla ML dello sviluppo di Spyro (sentitevi
liberi di usare indistintamente l'italiano o l'inglese) [2].

[1] http://code.google.com/p/spyro/issues/list
[2] http://groups.google.com/group/spyro-dev oppure
spyro-...@googlegroups.com

Grazie a tutti e buona serata.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

Il giorno 09 aprile 2011 19:49, Roberto De Ioris  ha
scritto:

> Visto che ci sei ti consiglio di generalizzarlo un pochino, in modo che
> sia facile subclassarlo per poter usare altri motori di storage (database,
> nosql, cache engine...)
>
> Non sottovalutare questo aspetto, poter condividere le sessioni tra piu'
> macchine e' una parte vitale.
>

Fatto :)
Il session manager ora ha un nuovo approccio. La classe Session è un
semplice middleware e stabilendo una convenzione (come il nome della classe
di storage, e aggiungendo man mano che si creano i nuovi storage nel
register.py -poichè esegue opportuni controlli-) carica dinamicamente in
base ad una nuova direttiva 'storage' il backend necessario. Ho quindi
reimplementato quella file based. La prossima magari la realizzo simile a
quella di Flask e appena possibile appoggiandosi al db.

Non mi sembra di aver notato particolari falle in tale sistema, ma vista
l'ora è possibile che mi sia sfuggito qualcosa, se notate qualche problema
vi prego di segnalarmelo.

Di lavoro da fare c'e n'è sempre di più, se qualcuno è interessato a
collaborare... :PPP
Buona notte a tutti.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

Ho completato completato e testato la nuova classe SQLQuery che và a
sostituire le due funzioni sql_query e save che sono state sostituite quindi
da due classmethods. Come prima la connessione persistente (sessione) al
database viene creata alla prima richiesta sul database automaticamente,
senza bisogno di fare chiamate esplicite che vanno a rendere più complesso
il codice della webpage. Ho messo un nuovo esempio nella cartella examples
(cartella "database_app"), che sfrutta l'attuale implementazione della
classe SQLQuery, appena implemento il Model tale classe restituirà un model
rappresentante il risultato ottenuto anzichè il risultato del cursore.
Inoltre l'esempio mostra anche come è facile dal controller usare una view
per ogni situazione (penso fosse quello a cui si riferiva Roberto in una
mail precedente).

Buona serata a tutti.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

Il giorno 09 aprile 2011 19:49, Roberto De Ioris  ha
scritto:

> Visto che ci sei ti consiglio di generalizzarlo un pochino, in modo che
> sia facile subclassarlo per poter usare altri motori di storage (database,
> nosql, cache engine...)
>
> Non sottovalutare questo aspetto, poter condividere le sessioni tra piu'
> macchine e' una parte vitale.
>
>
Ci stavo proprio pensando prima, cosi forza troppo l'utente ad usare uno
storage su file. Ci lavorerò su, pensavo quasi di fare un'altro settaggio
per le sessioni chiamato "engine" o  "storage" per poter definire facilmente
qualche backend usare, e quindi a runtime, quando crea l'oggetto
Session(self) (in webpage.py, assegnandolo a self.session) usare il backend
appropriato.

Ora finisco una piccola modifica al file rawquery, al posto della funzione
sql_query metterò una classe SQLQuery cosi sfruttando questa classe sarà
possibile implementare anche più facilmente un sistema di sessioni basato su
database facendo collaborare il database manager e il session manager.

Non ho messo molti dettagli, ma se hai altri consigli sono tutt'orecchie :-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

Ho appena fatto il commit con la modifica consigliata da Roberto al session
manager. Ora effettua il lock sul file (con flock) nel corpo dello statement
with per gestire i file. Uscendo dal blocco con la chiusura si toglie il
lock (ero insicuro se dichiararlo esplicitamente, ma ho fatto dei test).

Grazie ancora a Roberto per la segnalazione :)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

Il giorno 09 aprile 2011 17:16, Daniele Varrazzo  ha
scritto:

> Nota che l'escaping che vedi non è fatto dal server, ma dal client. Tu
> scrivi "ciao mondo" in una form del client, e il client prepara una
> richiesta http che nel corpo (in caso di POST) o nella url (in caso di GET)
> contiene una versione www-form-urlencoded di quei dati, in più dichiara
> "Content-Type: application/x-www-form-urlencoded" nell'header della
> richiesta.
>
> Tutto questo credo avvenga ad un livello più elevato di wsgi. Quindi sì,
> l'escaping avviene a livello dell'applicazione
>

Chiarissimo.
Ho quindi implementato la modifica, ora è il framework che effettua
l'encoding.
Ho utilizzato come consigliavi tu stesso urllib (sotto python3 urllib.parse
fornisce le funzioni utili a questo scopo).

Ti ringrazio per la spiegazione, anche questo è un problema superato :-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

Il giorno 09 aprile 2011 15:32, Daniele Varrazzo  ha
scritto:

> Questo fa parte dell'html, wsgi si limita solo a passare questi dati da
> una parte all'altra.
>
Aggiungo, rileggendo il mio vecchio post ammetto di non essere stato chiaro,
davo per scontato quanto sopra, e per questo mi riferivo al protocollo WSGI,
per capire se definiva dove dovrebbe avvenire l'escape (se nel server o nel
framework), o almeno dare una linea di massima di come viene gestito nella
pluralità dei casi.

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

Re: [Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

Il giorno 09 aprile 2011 15:32, Daniele Varrazzo  ha
scritto:

> Le specifiche le trovi qui ad esempio
>  e in python c'è il modulo
> urllib che permette di fare encoding/decoding.
>
Ti ringrazio per il link, che quello è html ci arrivo, semplicemente mi
chiedevo se l'escaping dovrebbe essere a carico dell'applicazione (web
framework) o del server. Visto che wsgiref è un server minimale potrebbe non
includerlo, quando altri server potrebbero farlo e quindi fare l'escape a
livello del framework sarebbe poi inutile visto che non sarebbe mai usato
con un server di produzione.,

>
> Spero tu ti renda conto che dicharare "sto scrivendo un framework web" è
> un'affermazione abbastanza grossa. Il percent-encoding sta all'html come la
> marmellata sta alla colazione: mi auguro tu sappia quello che stai facendo
> :)
>
Ripeto, il mio dubbio era quello di chi dovesse effettuare l'escape, non
cosa fosse tale codifica.
Comunque sicuramente non sò tutto, questo è innegabile, e stando a quello
che dici tu oggi dovremmo ancora essere fermi all'assembly perchè all'epoca
non c'era conoscenza e quindi dire "sto creando un linguaggio più semplice"
era un azzardo :P
A scanso di equivoci, chiaramente non mi sono offeso, anzi ti ringrazio la
risposta.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

> Dai una occhiata a come Flask usa le sessioni. Ti risparmieresti un sacco
>> di grattacapi (tra cui la necessita' di condividere le sessioni su piu'
>> server quando vuoi distribuire l'applicazione).
>>
>
> Ho realizzato qualcosa di molto simile a quello in uso da Flask, ma alla
fine sono giunto alla conclusione che non è poi così usabile come soluzione.
Se salvassi sul client un dizionario serializzato con pickle e poi con
codificato con base64 l'utente se a conoscenza dei dettagli di
implementazione dell'applicazione (in qualche modo viene a sapere che si usa
un framework opensource), potrebbe facilmente ricavarsi i dati di tale
implementazione, quindi decodificare il dizionario, modificarlo e modificare
il cookie con il nuovo valore.

Avere un hash da qualche parte per verificarne il contenuto implicherebbe
comunque una persistenza dei dati server side perchè finita la richiesta
perdiamo tutti i dati e bisogna salvare l'hash e quindi poi poterlo
riconoscere.
Potrei ovviare al problema usando una keyword "secret" e con un algoritmo di
crittazione a chiave simmetrica, in modo da ricostituire poi il testo
originale e ripete l'algoritmo all'inverso per deserializzare il dizionario,
ma a questo punto dovendo perdere tempo a fare tutti questi calcoli mi
chiedo se realmente sia significativamente più efficente di una classica
soluzione file-based o db based (attualmente non supportata).

Se sbaglio qualcosa correggetemi pure.

Riguardo la possibilità di race conditions per l'implementazione attuale,
come dovrebbe comportarsi il session manager quando il file è già sotto un
lock? Dovrebbe aspettare che il file sia accessibile? oppure dovrebbe
semplicemente sollevare una eccezione, o ritornare silenziosamente al flusso
dell'applicazione senza aver fatto nulla?

Grazie mille.
PS. se in qualche modo creo disturbi scrivendo qui vi prego di farmelo
sapere, grazie.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

Ho risolto alcuni piccoli bug in session.py e register.py, che sono sorti
dopo una rivistazione della struttura del codice e che non avevo ancora
testato.
Con la revisione attuale funzionano perfettamente tutti gli esempi. Sto
intanto concludendo un esempio sfruttando anche le query in SQL e intanto
continuo in locale a progettare la classe Model. Appena finisco aggiornerò
il file TODO con maggiori dettagli, e magari ve ne parlo qui cosi potete
aiutarmi a migliorarne gli aspetti.

Buona giornata a tutti!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

Il giorno 07 aprile 2011 20:13, Roberto De Ioris  ha
scritto:

> Non ho guardato bene il codice ma piu' tardi lo scarico, comunque, sia
> mod_wsgi che uWSGI supportano Python 3/PEP da un bel po' di tempo
> (e credo anche cherrypy)
>

Ti ringrazio per avermi ricordato uWSGI. mod_wsgi non ho ancora avuto modo
di provarlo, con cherrypy ci stavo provando giusto la settimana scorsa ma
avevo qualche problema, devo riprovarci. Sinceramente temo ci sia da
cambiare qualcosa affinchè i dati siano thread-safe, anche se alla fine i
dati vengono elaborati ad ogni richiesta, gestita da un thread separato,
quindi non credo ci siano problemi di sorta. Se sbaglio qualcosa
correggetemi.

Altro problemino sorge con i dati in input ma credo sia proprio un problema
di escaping fatto da wsgiref. Ovvero, inserendo in un campo input "ciao
mondo" ottengo "ciao+mondo". Nelle specifiche WSGI non mi sembra di aver
trovato niente di rilevante a tale scopo, quindi dovrei prima provarlo con
un altro server wsgi e poi vedo se è il caso di tenere conto di questo
escaping.

Lieto di sapere che ne scaricherai i sorgenti :)

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

[Python] Spyro - web framework open source per Python3 in sviluppo ricerca collaboratori

[lex mlist]

Salve a tutti,

vi scrivo per parlarvi di un progetto che ho iniziato un circa un mesetto
fa.

Assolutamente non sono qui per "vendervi" un prodotto, visto che non è
ancora pronto, ma sono qui a parlarvi del progetto perchè mi piacerebbe
poter avere aiuti nello sviluppo, e poi sviluppare da soli non è così
divertente (:-)

Il progetto, che si chiama Spyro, è un webframework, scritto nativamente per
Python3. La scelta che mi ha spinto ad avviare questo tipo di progetto è la
totale o parziale assenza di supporto dai webframework attuali, verso questo
ambiente di produzione.
Visto che mi piace stare al passo coi tempi, e che devo sviluppare delle
applicazioni web nuove, ho pensato di iniziare io stesso a sviluppare un
framework.

Non voglio essere troppo prolisso, il codice lo trovate qui [1] e ha
opportuni commenti.
Il progetto si basa su tre principi:
 1- tutti i settaggi devono risiedere in un file esterno.
 2- sempre retrocompatibile.
 3- esplicito è meglio che implicito.

Il codice ha meno dipendenze possibili, perchè queste, essendo progetti di
terze parti potrebbero minare a quello che si vuole ottenere, specialmente
al #2, chiaramente alla fine ognuno usa quello che meglio preferisce, ma lo
scopo primario non è quello di consentire di scambiare prodotti di terze
parti sulla stessa base.

Una cosa che non ho mai sopportato di vari framework è che per passare
dall'ambiente di sviluppo a quello di produzione, quasi sempre devi cambiare
alcune cose al codice, spesso per settaggi cosiddetti hard-coded.
Al #1 ho pensato di porvi rimedio con un file esterno di configurazione,
sfruttando il fantastico YAML, e tutte le features che questo offre per
elaborare il file di configurazione che si passa poi per nome alla classe
Application che elabora il file. Questa è la base dell'applicazione WSGI.
Il vantaggio è quello di potersi basare su uno strumento di verifica che
permette di riconoscere errori vari. In questo modo il codice si scrive una
sola volta: per il testing e per il deploy. Tutto quello che deve cambiare
si cambia nella configurazione, e poi si esegue l'applicazione. In questo
modo si limitano i bug nell'applicazione derivati da errori fatti da
modifiche veloci dei settaggi. Le funzioni che esaminano i settaggi dovranno
essere opportunamente migliorate per garantire maggiore sicurezza.
Il #2 è un po' uno dei principi che muovono l'intera community di Python.
Troppo spesso però (in senso più generale) mi ritrovo io stesso a dover
riadattare i miei programmi per farli girare con nuove versioni delle
librerie o applicazioni di terze parti. Tutto questo non vuol dire che non
ci debbano essere miglioramenti o aggiunte di funzionalità, ma tutto quello
che cambia sotto la "corteccia" non deve minare la funzionalità di un metodo
messo a disposizione, e questi ultimi non devono essere rinominati, rimossi
o eseguire qualcosa di diverso da quanto originariamente previsto (va bene
farlo diverso ma deve fare quello). In questo modo spero di poter garantire
una base su cui lavorare in modo stabile e far girare una applicazione con
una qualunque versione del webframework, senza incompatibilità. Nuove
features e nuovi metodi sono quindi OK, ma piuttosto di rimuoverne uno
obsoleto stando a questo principio bisognerebbe usare un livello di
astrazione e quindi riscrivere il corpo del metodo/funzione e farlo
funzionare con i nuovi metodi.
Il #3 si riferisce un po' in termini generali all'approccio del framework.
Mi piace che le cose siano autoesplicative, e che ci siano opportuni metodi
per salvare i dati e cose simili, senza rendere misterioso come il framework
funziona. I programmatori non devono perdere tempo a capire come e/o perchè
una cosa funziona, ma devono concentrarsi solo sulla propria applicazione.

Il codice probabilmente è da riscrivere in qualche parte o magari solo
migliorare altre parti. Le poche applicazioni web che ho sviluppate per la
maggior parte le ho fatte in PHP (conosciuto Python son passato a cose di
basso livello in C) e da allora la mia mente è sempre rimasta un po' legata
a questo approccio, dove tra dev e deploy cambiano i settaggi del server e
poco o niente del codice. Anche se il web non è mai stato il mio target
primario, almeno non il web che si "vede", avendo lavorato a qualche
applicazione C/C++ di networking tra cui webserver.
Attualmente l'unico server WSGI già pronto che ho trovato per Python3 è
wsgiref e uso quello per i test, ma ho in progetto di riscrivere e
completare un server in C asincrono da interfacciare con le nuovi API
Python3.

Il framework attualmente fornisce tutto il necessario che mi è venuto in
mente per fare una applicazione, compreso il session manager (che magari non
sarà dei migliori ma funziona). Trovate nella cartella "devs/" una
alternativa al session manager che usa un'altro approccio, ma espone a
rischi di sicurezza descritti in cima al file, e comunque l'overhead
descritto nel file TODO [(!4) nella lista Future Versions] avviene solo la
prima volta ed è v

Re: [Python] Come scrivere uno script da installare in /usr/bin con setup.py?

[lex mlist]

Ti ringrazio Marco, la tua risposta è più che esauriente.
Ho letto il primo dei due link, domani impegni permettendomi leggerò per
bene anche il secondo :)

A questo punto non mi resta che provare, ammetto di non aver creato uno
script tipo quello di Van Rossum, ma il principio è lo stesso.
if __name__ == '__main__':
esegui_funzione()

Domani provo a rileggermi per bene anche il primo, magari mi sono perso
qualcosa (considerando che son saltato subito ai codici).

Il giorno 19 marzo 2011 17:43, Marco Giusti  ha
scritto:

> tu in realtà non hai bisogno di simulare il comportamento di
> setuptools/ecompagni quando in realtà ci penseranno loro a fare tutto il
> lavoro per te, in setup.py:
>
>setup(
>name='...',
># ...
>entry_points = {
>'console_scripts': [
>'nome_dell_eseguibile':
> 'package.some_module:main_func',
>]
>}
>)
>
>
Io lo script lo installavo con l'opzione 'scripts' come segue:

script( ...
   scripts = ['scripts/testdev.py'],
   ...
)

proverò quanto prima il sistema che mi hai appena illustrato.
Il file che modificavo era quello generato proprio dalla opzione 'develop'
sul file setup.py come appena descritto.
Pensavo potesse essere un problema del porting di setuptools alla versione 3
e quindi provai anche con 'install' (usando distutils) ma stesso risultato,
quindi sono giunto alla conclusione che fosse lo script scritto in maniera
errata.

Ovviamente chiamando l'interprete da terminale sul file lo stesso funziona e
fà quanto dovuto.

leggiti il post del sign. van Rossum e poi la documentazione di
> setuptools o di distribute, meglio, sopratutto il paragrafo che ti ho
> indicato.
>

Lo farò, in ogni caso (successo o ulteriori problemi) aggiornerò il thread
:)

Grazie ancora e buona notte!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Come scrivere uno script da installare in /usr/bin con setup.py?

[lex mlist]

Giorno a tutti,

quello che vorrei ottenere è uno script da eseguire per automatizzare alcuni
processi.
Non è conveniente spostare sempre lo script perchè potrebbe essere
utilizzato in qualsiasi directory, e quindi diverrebbe scomodo.
Non vorrei dover far settare a mano la variabile d'ambiente in cui ricercare
lo script.

Pensavo quindi di affidarmi al setup.py e all'argomento 'scripts' della
funzione setup.

Premetto  che l'ambiente deve usare Python3.x.
Ho provato a mettergli un file as-is, ma mi dà errore.
Esattamente mi dice che:

execfile(__file__)
NameError: name 'execfile' is not defined

Sò che nella v3 esiste solo exec...
Installando con l'opzione 'develop' il file prodotto è questo:

#!/Users/lexor/Desktop/test/bin/python
# EASY-INSTALL-DEV-SCRIPT: 'test==0.1','testdev.py'
__requires__ = 'test==0.1'
from pkg_resources import require; require('test==0.1')
del require
__file__ = '/Users/lexor/Desktop/test/test/scripts/testdev.py'
execfile(__file__)


Ho provato a dare una occhiata al file  generato e ho modificato execfile
con exec. Ma poi mi viene a dare un errore tipo:

Traceback (most recent call last):
  File "/Users/lexor/Desktop/test/bin/testdev.py", line 7, in 
exec(__file__)
  File "", line 1
/Users/lexor/Desktop/test/test/scripts/testdev.py
^
SyntaxError: invalid syntax

Avete qualche guida che spiega come creare uno di questi script? Ho guardato
la doc di distutils ma non spiega come crearli, solo come installarli...
Meglio se per py3, ma mi accontento anche di una versione vecchissima purchè
sia applicabile :s

Grazie a tutti, e auguri a tutti i papà della lista.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] [web] Il logging degli accessi a che livello dovrebbe essere effettuato?

[lex mlist]

Come da titolo,

il logging delle richieste in entrata e degli errori dovrebbe essere
effettuato a livello del webserver o della applicazione/framework?

Io penso che gli errori dell'applicazione debbano essere loggati dalla
stessa e tutto il resto (accessi compresi) dal server web, no?
E ancora, se uso nginx/apache come reverse-proxy per il server
dell'applicazione chi dovrebbe loggare gli accessi?

ps. se uso mod_wsgi o equivalente è necessario un server parallelo per
avviare l'esecuzione (classico server in python che avvia l'app) o basta il
solo server che ha il mod_wsgi?

Grazie a tutti e buona serata.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Introspezione - Ottenere implicitamente una variabile della classe parent

[lex mlist]

Ringrazio Francesco per la precisazione, in effetti anche io mi ero
soffermato solo sul metodo __init__().
Nessun problema comunque, grazie ancora ad entrambi per la disponibilità :D

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

[Python] Introspezione - Ottenere implicitamente una variabile della classe parent

[lex mlist]

Ciao a tutti,

mi trovo in una condizione particolare.
Ho una classe che contiene dei dati, e in questa classe viene istanziata a
sua volta un'oggetto che dovrebbe manipolare i dati contenuti nella classe
stessa.
Mi spiego con un esempio:

===
class A(object):
def __init__(self):
self.b = B()
self.txt = 'Ciao'

class B(object):
def saluta(self):
# accedere a self.txt della classe A
pass
===

Usando i metodi di B() attraverso A().b.saluta() vorrei che fosse stampato
il valore di self.txt

Potrei ovviamente passargli il valore per parametro, ma il problema è che le
funzioni reali devono manipolare parecchi dati e le funzioni vengono
utilizzate
in più punti del programma, per cui passare ogni volta tutti i dati
necessari si rende scomodo. Cosi pensavo di poter sfruttare il potere
dell'introspezione di Python.

Ho dato una occhiata al modulo 'inspect' ma purtroppo ho solo trovato come
accedere al caller, e in questo caso, non riesco ad ottenere uno stack
precedente
(probabilmente perchè effettivamente A() non è un caller di B() ma ne crea
solo una istanza, mentre il metodo è chiamato nello scope globale).

Come potrei risolvere?
L'introspezione mi farebbe comodo, e sarebbe anche utile imparare questa
cosetta :)
Come sempre resto a disposizione per suggerimenti di ogni tipo.

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

Re: [Python] Quale tra dict, tuple e oggetti collect ions risulta essere il più performante?

[lex mlist]

Io non ho detto che Python non permette di ottimizzare la ricerca, ho per
l'appunto chiesto se esistono magari altri tipi di dati (anche del modulo
collections) che sono pensati appositamente per situazioni analoghe alla
mia, qualcosa di più opportuno di un dizionario (sia per la gestione che per
la ricerca), visto che non ho visto cosa fornisce il modulo collections.

Visto che in Python per ricercare l'elemento mi limito a "x in container" mi
chiedevo su quali elementi tale ricerca potrebbe essere più veloce (che ne
sò io come python gestisce la cosa, per questo chiedo).

Per la tupla ok, il ragionamento ci stà, per il dizionario O(1) è quello che
avevo trovato anche io e quindi da subito ho adottato tale soluzione, ma poi
mi sono imbattuto nel modulo collections che definisce "Tipi di dato
contenitore ad alte prestazioni" (cit.) e quindi mi sono chiesto se magari
ci sono altri contenitori che dovrei valutare.

Riguardo l'ottimizzazione dell'algoritmo di ricerca intendo proprio quello,
in altri linguaggi, ad esempio in C, prima di pensare ad una struttura dati
migliore penserei ad ottimizzare l'algoritmo di ricerca nella struttura che
ho creato per l'occasione.

Comunque non importa, per ora vado avanti coi dizionari, quando ho tempo mi
guardo il modulo collections.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Quale tra dict, tuple e oggetti collect ions risulta essere il più performante?

[lex mlist]

Buondì,

la mia situazione è più o meno questa:
ho un dizionario in input di lunghezza indefinita (non ho proprio modo di
sapere a priori quale sarà il limite massimo, essendo un insieme di elementi
in cui fare una ricerca).

Ho poi la necessità di fare, in base ad altri dati in input, numerose
ricerche sul dizionario. La ricerca la faccio semplicemente comparando la
chiave, e in caso di match restituire il valore.
In altri linguaggi avrei pensato prima di tutto ad ottimizzare l'algoritmo
di ricerca, ma in python faccio semplicemente uso di 'x in dict.keys()'
Mi chiedevo quindi, essendo il numero di ricerche davvero molto elevato (ed
essendo il numero di elementi dell'insieme virtualmente illimitato), ci sono
oggetti che risultano essere più performanti del dizionario sia per la
ricerca che per l'estrazione di un valore?
Potrei organizzare una tupla assumendo alcune convenzioni (per esempio, sui
numeri dispari ci sono le chiavi, su quelli pari ci sono i valori, cosi da
ricavare la posizione della chiave, aggiungere uno e ricavare il valore).

Ho fatto dei test e ho visto che la set() risulta essere la più performante
ma purtroppo io ho la necessità di ricavare la posizione degli elementi (per
estrarre poi il valore collegato alla chiave) e quindi non posso usarla, poi
ho visto gli oggetti del modulo collections ma non li ho testati.

La chiave deve essere unica (quindi se l'oggetto in questione lo richiede
non è un problema), se l'oggetto non fà il controllo lo posso fare
tranquillamente io quando converto (eventualmente) il dizionario in un
oggetto che mi dà maggiori benefici in termini prestazionali.

Tutti i suggerimenti sono ben graditi,
buona giornata a tutti.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Semplificare l'importazione di oggetti da un package

[lex mlist]

No il problema l'ho risolto seguendo questo [1].

A quanto pare la soluzione migliore per evitare il problema è importare
quello che ti serve solo quando ti serve, io invece da buon developer di
C/C++ ho la tendenza ad importare tutto quello che mi serve/potrebbe servire
all'inizio del modulo.

Mi è bastato spostare lo statement di import dentro la classe che dipende da
Info.

Grazie mille per il suggerimento, c'era anche quella possibilità.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] SignedImporter [was: Criptazione dei file sorgenti per evitare la manomissione]

[lex mlist]

Il giorno 20 novembre 2010 13:21, Manlio Perillo
ha scritto:

> E' possibile che durante la fase di compilazione venga eseguito del
> codice Python, ma non saprei dirti con certezza; chiedi sul newsgroup
> inglese.
>

Proverò a chiedere, e tempo permettendo, a cercare prima ancora di chiedere
per evitare, eventualmente di riproporre un argomento magari trattato già
diverse volte :)

>
> Comunque, hai openssl 0.9.8 installato (librerie ed headers)?
>
Appena rientro (fine settimana) constrollo, stò usando un server freebsd
pulito dedicato proprio al testing, e potrei non averlo installato.
Comunque il 'configure' dovrebbe, penso, segnalare eventuali carenze di
librerie necessarie al corretto funzionamento di Python e (quanto meno) dei
moduli base.

> Ciao  Manlio
>
Ciao e buona serata, e grazie ancora per il supporto :)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Semplificare l'importazione di oggetti da un package

[lex mlist]

Sera a tutti,
visto che l'errore che ottengo è relativo a quanto sopra, non stò ad aprire
un'altro thread.

Questa è la mia situazione:
module/
module/__init__.py
module/submodule/__init__.py
module/submodule/application.py

In application.py dichiaro tre classi:
Application,
Info,
in un'altro file importato da application.py:
Dictionary

Info dipende da Dictionary (nel senso che lo usa per creare degli oggetti)

Quando faccio:
'from module.submodule.application import Application'
tutto funziona, ma quando provo a fare
'from module.submodule.application import Info'
mi restituisce un 'ImportError: cannot import name Info'

ma se faccio 'import module.submodule.application' e poi mi riferisco a Info
attraverso 'module.submodule.application.Info' funziona tutto.
Può dipendere dal fatto che con Info non importo anche Dictionary che però
viene usato da Info?
Per un idea migliore Info è definita cosi:

class Info(object):
a = Dictionary()  #dictionary è viene importato da 'application.py'


Questo è tutto, come mai questo strano comportamento?
(il package è installato con setuptools 'develop', python3)

Grazie mille a tutti.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Semplificare l'importazione di oggetti da un package

[lex mlist]

Il giorno 18 novembre 2010 22:12, Manlio Perillo
ha scritto:

> Ciao.
>
Ciao Manlio!

Di solito quello che si fa è:
>
> __init__.py
> from module import Classe
> from modulee import Classe2
>
>
> __all__ = ['Classe', 'Classe2']
>
>
> Volendo automatizzare, si, puoi utilizzare la variabile speciale __all__.
> Non dovrebbe essere difficile; la parte più delicata è la ricerca di
> tutti i moduli e sotto package (perchè devi comunque cercare di
> supportare i package zippati, come le egg).
>
Grazie mille per la tua gentilezza e disponibilità di sempre :)

Ho capito, bene farò come dici. Magari appena sotto gli import di module e
module2 definisco una __all__ cosi da __init__.py spero di importare solo
ciò che ho definito in __all__ stessa, potendo sfruttare il "from module
import *"


> > [...]
>
>
> Ciao   Manlio
>

Grazie ancora =)
Ciao e buona notte!!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Semplificare l'importazione di oggetti da un package

[lex mlist]

Sera a tutti,
beh le mie limitate conoscenze con Python si notano probabilmente da
messaggi come questi (per cui mi scuso).

Ho provato a cercare ma non ne sono venuto a capo.
Supponiamo la seguente situazione:
/package
/__init__.py
/package/module.py - definisce Classe
/package/module2.py - definisce Classe2
/setup.py

supponiamo che io voglia permettere di importare Classe usando 'from package
import Class' al posto di 'from package.module import Class' faccio che
importare in __init__.py module.Class.

Esiste un modo per automatizzare il tutto? Magari sfruttando la lista
__all__
Intendo che automaticamente si cerca nel package e in eventuali sub-packages
per eventuali classi/funzioni (magari discriminate da __all__) e le importa,
permettendo di importare suddetti oggetti senza dover specificare anche il
nome del file che li specifica.

Questo mi tornerebbe molto utile, perchè se cambio poi il nome del file che
definisce una classe devo andarmi a ricorreggere tutti i file che ne
facevano la chiamata, mentre l'automazione mi torna utile per evitare di
dover modificare __init__.py ad ogni modifica.

Grazie mille e buona serata a tutti.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] SignedImporter [was: Criptazione dei file sorgenti per evitare la manomissione]

[lex mlist]

Il giorno 17 novembre 2010 13:43, Manlio Perillo
ha scritto:

> Il problema è che stiamo parlando di un programma probabilmente
> acquistato da un utente e che molto probabilmente gira sul suo computer.
>
> Se l'utente vuole fare danni, saranno anche problemi suoi, no? :)
>
Ahahah, si probabilmente hai perfettamente ragione :D
In effetti in certi casi converrebbe lasciar perdere e permettere di far
fare all'utente ciò che vuole.


> Ed in questo caso secimport non va bene; i moduli dovrebbero essere
> criptati.
>

Ed anche questa sarebbe una bella soluzione, magari implementando una
modifica a CPython che permetta facilmente di aggiungere moduli che ne
modificano il comportamento di import. Ma questa è una cosa che si può fare
in seguito, e il code obfuscation (a mo' di PHP) non la trovo affatto una
soluzione, oltre che una cosa davvero 'anti-pythonic', e poi sinceramente
non sò se sia possibile fare del code obfuscation con python, perchè il
massimo che si potrebbe fare è cambiare i nomi delle variabili, ma non (per
esempio) splittarlo tutto su una riga (mi sembra di aver visto ';' ma
sinceramente non sò quanto permetta). :E


> Questo potrebbe essere un buon motivo; e per risolvere questo problema
> non è nemmeno essere paranoici per la sicurezza.
>
Beh allora la cosa inizia a prendere senso, curiosità a parte :)

Potrebbe essere questo il problema.
> In questo caso devi inizializzare tu hashlib (ma possono succedere
> casini se poi il runtime di Python la reinizializza in seguito).
>

> > Per provare ho lasciato passare l'errore, la soluzione definitiva
> > sarebbe o fare il modulo in C (come lo è zipimport)
>
> Ma dovrai comunque inizializzare il modulo.
> Vedi ad esempio l'API C di cStringIO.
>
> Per hashlib il modulo da inizializzare è _hashlib (Modules/_hashlib.c);
> se questo modulo non può essere importato, allora vengono usati i vari
> moduli _md5, _sha e così via.
>
> Mi strano comunque che ti dia l'errore su _md5, dato che secimport di
> default usa sha1.
>
>
A me sembra strano che in fase di compilazione tenti già di eseguire i
moduli, mi sarei aspettato un simile comportamento solo in fase di
inizializzazione dell'interprete, non in fase di compilazione :3

In che modo potrei inizializzare il modulo '.c' se non è stato compilato?

Riguardo l'algoritmo infatti suona strano anche a me, ma stando all'errore è
riferito proprio al file 'hashlib.py' (nei sorgenti sotto la cartella Lib)
e la funzione incriminata che non trova il modulo _md5 è:
__get_builtin_constructor(name) (se non ricordo male, vado a memoria adesso
che non posso avviare la compilazione), e come dici tu, in caso non trova
_hashlib importa gli altri singolarmente.


> > [...]
>
> > PS. a questo punto, se dovesse rendersi necessario il fare troppe
> > modifiche all'interprete per via di vari problemi nei moduli, si
> > potrebbe pensare ad includere un nuovo file .c all'interprete
>
> Oppure al tuo programma che wrappa l'interprete.
>
Anche, si però assieme al programma comunque bisogna distribuire la copia
dei sorgenti in Python (per la compilazione, o comunque farla recuperare),
perchè deve modificare il comportamento standard di Python.

>
> > e rendere
> > il controllo parte integrante dell'interprete stesso, ovviamente se
> > dovesse essere necessario farlo su *tutti* i moduli, permettendo però,
> > di inserire in qualche modo il dizionario con le chiavi.
>
> Vedi lo script build_signature_database.py.
> Lo si può modificare per fargli generare codice C che definisca il
> dizionario.
>
> Prima di fare questo, però hai bisogno di una instanza di CPython
> "pulita" per creare il dizionario.
>

Ottima idea quella dello script. La necessità di avere una copia "pulita" di
CPython non penso sia uno svantaggio, proprio perchè almeno ciò che deve
fare lo sviluppatore (generare il dizionario) in questo modo lo può fare in
Python.
E poi, tolto Windows, sia Linux, che BSD che Mac OS X (non mi ricordo di
preciso su quest'ultimo, perchè gli ho subito installato XCode e dipendenze
varie) hanno Python di default.


> Ciao   Manlio
>
A scanso di equivoci, ho scritto dall'ufficio, accanto ad una segretaria un
"poco" chiacchierona, quindi potrei non aver rappresentato correttamente i
miei pensieri e/o potrei essere stato deviato dal discorso originario con
qualche affare di tipo burocratico/economico :E

Ciao e buona serata.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] SignedImporter [was: Criptazione dei file sorgenti per evitare la manomissione]

[lex mlist]

Il giorno 17 novembre 2010 10:31, Gian Mario Tagliaretti
ha scritto:

>
> Visto che hai fatto l'esempio dei CAD
>
> Autodesk Maya
> http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13577897
>
> Autodesk Plant 3D
> http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=12261005
>
> entrambi hanno Python embedded, sul secondo (Python .net) ci sta lavorando
> la mia società per integrare un nostro prodotto usando le API Python, magari
> investigando sul loro forum ottieni qualche risposta tecnica
> sull'integrazione, io purtroppo non ho tempo.
>
>
Molto interessante, farò come hai detto per scoprire qualcosa sulla loro
integrazione, visto che parliamo di Maya, segnalo comunque anche Blender che
usa Python per l'interfaccia grafica e adesso il team stà lavorando proprio
per migliorare la loro integrazione e poter programmare in Python altri
aspetti dell'applicazione.


> ciao
>
Ciao ciao, e grazie mille per la segnalazione molto interessante!
p.s. Se dovessi avere altre informazioni e magari del tempo e voglia, io
resto a disposizione =EE
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] SignedImporter [was: Criptazione dei file sorgenti per evitare la manomissione]

[lex mlist]

Il giorno 16 novembre 2010 13:35, Manlio Perillo
ha scritto:

> Il problema però è capire i casi di uso.
> In quale casi hai bisogno di verificare l'integrità di tutti i moduli
> Python utilizzati?


> L'unico caso di uso che mi viene in mente è quando l'interprete python
> viene eseguito con privilegi particolare (ad esempio root, oppure
> accesso a porte IP).
>

Penso che sia necessario, oltre ai casi da te citati, nel caso in cui ad
esempio Python venga utilizzato come scripting di un altro motore (poniamo
l'esempio di un motore grafico, o di una applicazione tanto complessa da
rendere necessaria tale scelta). In quel caso, qualora si possa voler
preferire un linguaggio già pronto (anzichè fare un nuovo interprete che
magari supporti i file binari per proteggere anche la logica), si rende
necessario il poter operare in tutta tranquillità in una sandbox, e quindi
controllare che non vi siano manomissioni a uno qualunque dei moduli
utilizzati (altrimenti si comprometterebbe la stabilità e il flusso di
lavoro del programma).
Per fare un esempio mi vengono in mente solo applicativi di una certa
stazza, che probabilmente, visto il loro valore, non si appoggerebbero mai
ad una soluzione che ne esponga la logica.

Boh, adesso non saprei precisamente il perchè di una scelta, magari come
dici tu è solo perchè da root potrebbe compromettere l'intero sistema, ma se
è un software destinato ad uso professionale penso che anche se non venga
eseguito da root dovrebbe garantire sempre la corretta esecuzione, pensa se
un utente modifica i file python, magari per sbaglio, e poi lavora sul
software (poniamo che sia di disegno tecnico), clicca su 'Salva' e si rende
conto che il menù File non funziona perchè la relativa funzione python è
stata compromessa (e non è rara la scelta di un linguaggio di scripting per
gestire l'interfaccia grafica, anzi). Invece controllando, all'avvio,
eventualmente segnala che il programma necessita di essere reinstallato e
boh.

Se ho sbagliato qualcosa, correggetemi pure.
Probabilmente ci sono altre motivazioni più valide, ma che non mi vengono in
mente.

>
> Al momento non sono sicuro della differenza tra i due, dovrei leggere il
> codice.
>

Io prevedo di farlo stasera, se ho un po' di tranquillità, nel caso scopro
la differenza la posto qui subito.

> > [...]
> > Unico problema trovato in fase di compilazione del sorgente è che il
> > modulo hashlib crea un errore cercando di importare _md5, anche se,
> > onestamente, non capisco perchè in fase di compilazione tenti di
> > eseguire il modulo signedimporter (che importa hashlib).
> >
>
> Parli della compilazione di python?
>

Si, dopo aver modificato la '_PyImportHooks_Init' e compilando ottengo
quell'errore. Se uso la stessa gestione che usano per zipimport ovvero, in
caso di errore passaci sù, funziona giustamente. Però poi anche a runtime ad
ogni avvio quella sarebbe la gestione dell'errore. Probabilmente avviene
perchè hashlib non ha ancora accesso a tutte le sue dipendenze (magari
devono essere compilate).
Per provare ho lasciato passare l'errore, la soluzione definitiva sarebbe o
fare il modulo in C (come lo è zipimport) o magari trovare un modo per
aggirare il problema di hashlib.


>
> Ciao  Manlio
>

Ciao e buona serata.
PS. a questo punto, se dovesse rendersi necessario il fare troppe modifiche
all'interprete per via di vari problemi nei moduli, si potrebbe pensare ad
includere un nuovo file .c all'interprete e rendere il controllo parte
integrante dell'interprete stesso, ovviamente se dovesse essere necessario
farlo su *tutti* i moduli, permettendo però, di inserire in qualche modo il
dizionario con le chiavi. Però mi suona di cosa che necessita la modifica
dell'inizializzazione di CPython, perchè dovrebbe poter accedere ad un dato
runtime (il dizionario), prima dell'inizializzazione e quindi
dell'esecuzione effettiva del programma: forse la soluzione non è fattibile.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [ANN] secimport

[lex mlist]

Ma bene :)
Seguo con attenzione gli sviluppi, e mi permetto di usarlo per test, e usare
i file aggiornati al posto del signedimporter di paste, per la modifica a
CPython.
Se faccio modifiche o scovo qualcosa (o se ho dubbi) ti avviso :)

Buono sviluppo!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] SignedImporter [was: Criptazione dei file sorgenti per evitare la manomissione]

[lex mlist]

Il giorno 15 novembre 2010 20:13, Manlio Perillo
ha scritto:

> Se embeddi l'interprete, ti basta settare il flag Py_NoSiteFlag.
>
Ah, beh tanto meglio :)


> Scusa, ma nel tuo caso chiami l'interprete dalla riga di comando, o è
> incluso nella tua applicazione?
>
Nel progetto di cui alla discussione precedente includo l'interprete nel
programma C, però visto che tale thread è stato cosi ricco di spunti ho
pensato di provare a vedermi un po' il meccanismo di import di CPython.

Peccato che questa funzione non sia personalizzabile.
>
> Io l'ho modificata per caricare, assieme a zipimport, anche il modulo
signedimporter (quello tuo da paste, anche se incompleto mi serviva per
test.
Per maggiore sicurezza, però, anzichè usare il comportamento standard di
python con zipimport,(ovvero, che se non riesce a caricare il modulo o ad
ottenere un riferimento alla funzione/classe che gestisce l'import scrive
sullo stderr solo in caso di PYTHONVERBOSE) ho preferito far stampare
l'errore ed interrompere l'esecuzione dell'interprete (scelta non
necessariamente definitiva).

Ho notato comunque che zipimport viene registrato non in sys.meta_path ma in
sys.path_hooks.
Stando alla PEP302 mi pare di aver capito che la differenza è che
sys.meta_path viene controllato *prima* della creazione di sys.path.
E poi in meta_path si parla di importer mentre in path_hooks di oggetto
callable. :S

Per ora funziona tutto, cioè non ci sono errori a runtime anche se
giustamente, il modulo signedimporter non fà nulla e poi dovrò aggiungere un
controllo integrato per la validità dello stesso .py (magari poi lo rifarò
in C se conviene).

Unico problema trovato in fase di compilazione del sorgente è che il modulo
hashlib crea un errore cercando di importare _md5, anche se, onestamente,
non capisco perchè in fase di compilazione tenti di eseguire il modulo
signedimporter (che importa hashlib).


> Ti consiglio anche di chiedere sul newsgroup inglese.
>
>

Uhm, gli darò un'occhiata. Sicuro che non mi mangiano se parlo di modificare
la base di python? =E


> Ciao  Manlio
>

Ciao ciao!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] SignedImporter [was: Criptazione dei file sorgenti per evitare la manomissione]

[lex mlist]

Il giorno 13 novembre 2010 22:49, Manlio Perillo
ha scritto:

> Ecco un proof of concept, basato sul PEP 302:
> http://paste.pocoo.org/show/290997/
>
Eccomi,

Manlio ti chiedo scusa se non ho risposto subito ma ho preferito un attimo
leggermi la PEP302,  studiarmi il tuo proof e fare qualche prova di mio.

Premetto di aver lavorato sulla versione 3.0.1.
Ho scoperto leggendo la documentazione su 'site' [1] che l'import di
quest'ultimo e disattivabile passando l'opzione -S

Poi mi sono guardato per bene la PEP302 e il tuo esempio (per il quale ti
ringrazio).

Ho scaricato in seguito i sorgenti di Python3.0.1, e mi sono guardato il
meccanismo di import e la funzione Py_Initialize.

> Svantaggi
> =
>
> Per disabilitare la verifica delle firme, all'utente basta (a scelta):
> * modificare la funzione __import__
> * rimuovere l'importer da sys.meta_path
>
> Ovviamente questo è un problema solo se permetti di importare moduli
> "untrusted"; ma il caricamento di un modulo untrusted fallirà comunque,
> con la politica di default (permetti solo l'import di moduli "noti" ed
> integri).
>
> L'unica precauzione è *disabilitare* gli hook eseguiti all'avvio
> dell'interprete, ad esempio il caricamento di site.py; questo perchè gli
> hook permettono di eseguire codice utente arbitrario *prima* che
> l'importer hook sia stato registrato (XXX check me).
>

Volendo evitare ogni volta l'opzione -S, e potendo usare una versione
modificata (non pesantemente, solo per permettere di prevenire gli
auto-import iniziali), una soluzione sarebbe quella di modificare la
funzione 'Py_Initialize' disabilitando tutti gli import automatici, e
quindi, permettendo di registrare subito il tuo SignedImporter, poi si
importano eventualmente i file site.py ed altri necessari al corretto
funzionamento e/o preparazione dei dati necessari a runtime.
La funzione in oggetto si trova nel file 'pythonrun.c' [1].
Leggendola però si nota che la funzione '_PyImportHooks_Init' viene invocata
appena prima di importare 'site' e addirittura prima di creare __main__.

La funzione '_PyImportHooks_Init' si trova invece nel file sorgente
'import.c' [2].
Questa è parecchio più interessante e permette di importare direttamente il
SignedImporter (viene usata default per importare il modulo' zipimport'), di
registrarlo in sys.meta_path e quindi di anteporre il tuo metodo di
importazione persino a site.py (che quindi potrà essere verificato tramite
hash).

Le strade che ho trovato fino ad ora sono quindi due, nel primo caso puoi
fare tutto direttamente anche da file '.py' dovendo però importare anche
'site' e gli altri import necessari, posticipando quindi una parte di
inizializzazione dell'interprete.
La seconda strada invece è fattibile modificando appunto l'import hook
iniziale, caricando il modulo che contiene il SignedImporter (l'hash in
questo caso deve essere verificato però da C, poi ci penserà il modulo
stesso a farlo per gli altri). In questo caso devi distribuire anche il
modulo signedimporter.py però con l'interprete altrimenti non lo trova.

Per aumentare la sicurezza, nel secondo caso, sarebbe necessario operare
diversamente da come fanno per 'zipimport' perchè, in quel caso in assenza
del modulo in questione, non causa alcun errore, puliscono l'errore, e in
caso sia definita la variabile d'ambiente PYTHONVERBOSE mostra su stderr il
messaggio di errore, ma continua per i fatti suoi. Nel nostro caso invece
sarebbe opportuno, in assenza del signedimporter , di segnalare l'errore e
terminare l'esecuzione altrimenti si perde il senso di tutto il lavoro
fatto.

Queste sono le due strade che mi sono venute in mente leggendomi quella
parte di codice sorgente CPython relativa all'import.
Adesso stò provando a lavorare sulla seconda strada, appena realizzo
qualcosa di usufruibile vi segnalo la patch cosi potrete provarla,
intanto sono aperto ad eventuali consigli/esperienze e analisi da voi che ne
sapete più di me :)

[1]
http://svn.python.org/view/*checkout*/python/trunk/Python/pythonrun.c?content-type=text%2Fplain
[2]
http://svn.python.org/view/*checkout*/python/trunk/Python/import.c?content-type=text%2Fplain

Ciao   Manlio
>
> Ciao ciao e buona giornata!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Criptazione dei file sorgenti per evitare la manomissione

[lex mlist]

Il giorno 13 novembre 2010 20:01, Manlio Perillo
ha scritto:

> Si. Un semplice hash (SHA1, SHA e simili) oppure una firma tramite
> cifratura a chiave pubblica.

Tieni conto che è comunque suscettibile di attacchi, dato che devi
> memorizzare le firme da qualche parte.
> Se il core è in C, la manomissione è difficile ma non impossibile
> (credo, non ho esperienze a riguardo).
>

Si magari si trova qualcosa di alternativo, comunque è veramente una cosa
difficile, ma penso che usando opportune tecniche di obfuscation del codice
si riesca a mettere in difficoltà qualsiasi strumento di disassembling,
persino del calibro di Ida (ovviamente parliamo di opcode), se ti potrebbe
interessare (in caso contrario puoi tranquillamente ignorare):  opaque
predicates, junky bytes, e altri piccoli trucchetti come punti di ritorno
falsi, e altri giochini in assembly puro che permettono davvero di
complicare il lavoro a chiunque (anche se in termini assolutistici non
saprei dire in quale percentual, sebbene approssimativa al nullo, possa
essere fattibile il reverse engineering anche con tali condizioni.
Ovviamente l'intera lista comunque va a complicare il codice sorgente e non
poco :s quindi direi non proprio nello stile di python :))

La parte tecnicamente più complessa è verificare l'hash.
> Una idea è farlo al momento in cui avviene l'import di un modulo; per
> questo prova a dare una occhiata al modulo ihooks (non documentato, devi
> leggere il codice).
>

Si ci avevo pensato, ma non ero a conoscenza di questi strumenti. Io avevo
pensato di modificare eventualmente l'interprete di CPython, aggiungendo in
caso di import le relative funzioni per operare sul modulo da importare e
poi ritornare al flusso standard del programma.
La cosa è fattibile e per altro segna una svolta decisiva contro gli
strumenti già pronti per la decompilazione dei file sorgenti criptati.
Purtroppo (o non) si va a sacrificare l'interprete CPython standard perchè
il programma deve essere eseguito dalla versione modificata dell'interprete.


>
> Oppure dai una occhiata a
> http://www.python.org/dev/peps/pep-0302/
>
>
>  Banale non lo è di certo, diciamo che la trovo comunque molto
interessante, sinceramente pensavo ci fossero già buoni progetti in corso di
realizzazione in questo senso, ma mi sembra che siano più i decompilatori
pyc pyo che i compilatori per proteggere il programma.

La cosa non è comunque banale; magari se trovi una soluzione condividila!
>

Ovviamente, sono in debito con la comunità per quanto state condividendo con
me, e comunque anche per piacere personale, se troverò qualche soluzione
sarete i primi ad essere informati :)


>
> Ciao  Manlio
>
Ciao e buona serata!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Criptazione dei file sorgenti per evitare la manomissione

[lex mlist]

Il giorno 13 novembre 2010 19:44, Raffaele Salmaso <
raffaele.salm...@gmail.com> ha scritto:

> On 11/12/2010 09:36 PM, lex mlist wrote:
> > Esattamente che cosa intendi con "lua è molto più parco di risorse"?
> che è pensato per girare con meno risorse: l'interprete pesa circa 100kb
>
Ti ringrazio per la precisazione, ora mi è più chiaro :)


> no.
> se la cosa ha senso, e solo tu come creatore del programma lo sai,
> potresti fare una cosa del genere: quando hai bisogno di elaborare i
> dati, li mandi al server che poi li restituisce al client. In pratica
> esponi un'api rest.
> Ovvio questo non ha sempre senso, dipende anche dal contesto del programma.
>
Si nota che non ho mai usato un approccio di questo tipo, non ci avevo
pensato, ed in effetti è una bella soluzione.
Non la userò per il progetto corrente perchè davvero non serve, ma la
realizzerò cosi, a tempo perso per test e curiosità personale,
che fonte di illuminazione questa MailingList :D

> ok, allora ti basta questo
>
> http://bitbucket.org/ubernostrum/django-funserver/src/tip/funserver/management/commands/funserver.py
>
> :D
>
ahahahaha, buono spunto. ma è una cosa che funziona per davvero?
non resisto, vado a provarlo :p
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Problema con la condivisione e l'utilizzo di un dict globale

[lex mlist]

Si immagino che il problema quindi sia nel design dell'applicazione, perchè
l'import già adesso e sicuramente pensavo di usarlo in un'altro modulo che
non è quello finale, e quindi si otterrebbe una cosa del genere:
error importa application, altri file del package usano error, il file
main.py include application e usa application.

error e gli altri file però avrebbero bisogno dei dati del file yaml senza
che main.py li includa (vengono usato direttamente dal package non sono per
il file main.py), speravo che avviando il tutto a runtime funzionasse,
perchè creo prima application e poi uso tutte le altre feature del package
(tipo error).
Mi sà che allora mi tocca trovare una strada alternativa. Il file yaml mi
tornerebbe utile perchè per modificare il comportamento del programma mi
basterebbe modificare quel valore e lanciare di nuovo il programma anzichè
rimettere mano al sorgente e, magari, andare a modificare tutte le chiamate
a error per settare debug a True o False. Non si tratta comunque solo di una
flag di debug, ma anche di informazioni aggiuntive che si definiscono a
runtime ma che servono ai file importati internamente.
Probabilmente stò incasinando io stesso il design, metto un po' di ordine e
magari se non riesco lo espongo meglio.

Riguardo l'uso del logger, si ci avevo già pensato, ma ancora non sono
riuscito a capire come settare solo in un punto del programma il tipo di
logging richiesto (per dire, se poi voglio disabilitare i messaggi di debug
non vorrei dovermi modificare tutti i file per cambiare il valore
logging.DEBUG).

Riguardo invece il fatto di __debug__ hai perfettamente ragione, la logica
da C mi ha indotto a pensare che fosse una macro, mentre è una variabile
python, probabilmente potrebbe essere migliore, ma forse complica troppo le
cose o rallenta troppo l'esecuzione boh, chissà (bisognerebbe chiedere al
Guido in persona).
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Criptazione dei file sorgenti per evitare la manomissione

[lex mlist]

Il giorno 13 novembre 2010 15:22, Manlio Perillo
ha scritto:

>
> In casi come questo, invece che criptare/nascondere potresti firmare
> crittograficamente i vari moduli.
>
Intendi che dovrei ricavare l'hash del file originale e compararlo con il
file che vad ad eseguire per accertarmi che non ci siano manomissioni?
Se è questo, l'idea è geniale! Non ci avevo pensato mai prima d'ora.

> Ciao  Manlio
>
Ciao Ciao Manlio, grazie mille =)


Il giorno 13 novembre 2010 15:53, enrico franchi
ha scritto:

> Perche' so cosa vuole dire open source. Se ti leggi la definizione, e'
> piuttosto banale vedere che hai errato

Mi sembra piuttosto arrogante questa tua risposta, perdonami se te lo dico.
Comunque beh, premettendo che non voglio assolutamente discutere ne
scatenare flame di qualsiasi genere, penso che sia una definizione piuttosto
personale di ciò che si intende correlato ad un software. Io sono cresciuto
con la convinzione di non fidarmi di nessuno, e non assumo per oro ciò che
mi dice il sito "opensource.org". Ti spiego perchè penso che sia una cosa
molto personale (ma non per questo non la rispetto essendo opinione altrui):
"no discrimination against persons or groups". Qui si parla tutto tranne che
di software, mi sembra un aspetto molto più "umanistico" e rivolto al
sociale, "license must be technology-neutral". Più che una definizione di
quello che si può voler intendere per open source a me sembra una chiara
linea guida da seguire se vuoi sottoporre una tua licenza al sito, poi ad
ognuno il suo pensiero. Continuerò a tenermi per buona la mia convinzione di
open source e rispetto la tua, al massimo se la cosa ti infastidisce in
futuro cercherò di evitare open-source in favore di altri termini.

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

Re: [Python] Criptazione dei file sorgenti per evitare la manomissione

[lex mlist]

Il giorno 13 novembre 2010 14:24, Enrico Franchi
ha scritto:

>
> On Nov 13, 2010, at 12:23 PM, lex mlist wrote:
>
> > Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente
> decompilabile, hai quindi una qualche alternativa?
> > oppure un programma python è destinato a rimanere open source!?
>
> Open source vuole dire una cosa ben precisa. Avere i sorgenti in mano non
> vuole dire essere open source.
>
Uhm solitamente si tende a confondere open source con freeware, io non
intendo dicendo "open source" che deve essere gratuito, sia chiaro, intendo
proprio quello che vuol dire ovvero a sorgenti aperti (visibili), perchè
ritieni che l'abbia usato impropriamente?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Problema con la condivisione e l'utilizzo di un dict globale

[lex mlist]

Il giorno 13 novembre 2010 14:23, Marco Giusti  ha
scritto:

> l'ottimizzazione del bytecode python è molto superficiale, per quanto ne
> sò tutto quello che viene fatto è la rimozione di alcuni statement: gli
> ``assert``, ``__debug__`` viene impostata a ``False`` e vengono
> eliminati (azzerati?) tutti gli attributi ``__doc__`. il test sulla
> variabile ``__debug__`` è un piccolo extra ma neanche troppo furbo,
> tempo fa' non era in grado di eliminare questo statement:
>
>if __debug__ and var:
>...
>
> ora non saprei.


Testato giusto ora, e per l'appunto non lo fà, comunque credo sia giusto
cosi, perchè se non c'è la __debug__ sà di poter evitare di scrivere il
blocco condizionale, perchè probabilmente essendo una variabile globale
riservata all'interprete (non sò se sia possibile definirla o meno, passami
il termine), con -O viene omessa e boh, ma nella presenza di un operatore
"and" con una variabile da verificare a runtime non può evitare di includere
il blocco.

Boh, non so se mi son spiegato, questa è la mia teoria per quello che ho
visto da stamattina ad ora :)


>
>python -O -c 'import mymodule'
>
> Oh beh, non è un grosso problema, importo tutti i moduli in maniera
ricorsiva (mi pare di aver visto un sistema per farlo), e dovrei avere tutti
i bytecode.

Purtroppo ancora non son riuscito a risolvere il problema di cui il thread,
ho provato aggiungendo la keyword global ma non funziona uguale :(
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Problema con la condivisione e l'utilizzo di un dict globale

[lex mlist]

Ma sai che non funziona?

questa è la classe ora:

class Application(object):
def __init__(self, filename):
self.filename = filename

def setup(self):
try:
global configuration
configuration = yaml.load(open(self.filename))
except IOError:
exit('configuration file not found: %s' % self.filename)

print(configuration)


ma se poi importo configuration e provo a stamparlo dopo aver chiamato
Application("configuration.yml").setup()
mi restituisce sempre "{ }"

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

Re: [Python] Criptazione dei file sorgenti per evitare la manomissione

[lex mlist]

Il giorno 13 novembre 2010 12:32, Paolo Bernardi  ha
scritto:

> Ben detto! Un ragionamento di questo tipo (costi/benefici) è proprio
> quello che devi fare.
>

=)) beh sono contento ogni tanto di far qualcosa nel senso giusto :D


>
> > Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente
> > decompilabile, hai quindi una qualche alternativa?
> > oppure un programma python è destinato a rimanere open source!?
>
> L'alternativa più sicura, come detto (mi pare) in questo thread, è avere
> la parte più significativa del programma lato server. Tuttavia devi
> sempre valutare i costi e i benefici della scelta; da quanto ho capito
> nel tuo caso distribuire i file pyc, magari inclusi in un qualche
> eseguibile, dll o quant'altro, è più che sufficiente.
>
>
Si nel mio caso và più che bene la soluzione .pyc, però mi piace conoscere
le cose sia per possibiltà future che per innata curiosità :)
Tanto per, proverò comunque qualcosa di tipo client-server perchè mi
interessa davvero molto.

2010/11/13 Massimiliano Pippi 

> Dai un'occhiata anche a questo vecchio thread
> http://lists.python.it/pipermail/python/2009-June/006900.html
>
Grazie, me lo leggo subito :)


> Ciao
>

Ciao, e grazie di nuovo a tutti!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Problema con la condivisione e l'utilizzo di un dict globale

[lex mlist]

Il giorno 13 novembre 2010 12:19, Marco Giusti  ha
scritto:

> On Sat, Nov 13, 2010 at 11:45:37AM +0100, lex mlist wrote:
> > Giorno,
> >
> > torno alla carica con un'altro problema (e chiedo scusa se vi stresso).
>
> no problem
>

=)) grazie mille per la risposta.


> [...]
> global configuration # <<< here the trick
> [...]
> ``configuration`` fa parte dello scope globale, quando dentro la
> funzione setup tu fai l'assegnamento
>
>configuration = yaml.load(open(self.filename))
>
> tu leghi (bind) il nome configuration allo scope locale. quando da
> dentro la funzione cerchi il nome ``configuration``, lui lo trova nello
> scope locale e ritorna quello, ovvero i parametri di configurazione, ma
> dal modulo ``error`` tu ottieni la variabile che è associata allo scope
> globale.
>

Accipicchia che comportamento "strano" :s
Non posso che chiedermi il perchè di un tale comportamento, si verifica solo
all'interno delle classi o in presenza di qualunque scope non globale?
(funzioni ed altro, se esiste)

Comunque grazie mille per l'aiuto, avevo davvero provato di tutto, anche ad
usare una classe al posto del dict ma il risultato finale è sempre stato lo
stesso.


> un piccolo extra che puoi ignorare se credi.

Nono, anzi tutt'altro, ogni informazione in più è utilissima :)) e ti
ringrazio in anticipo


> python mette a disposizione
> una variabile globale, ``__debug__``, che è sempre vera a meno di
> eseguire l'interprete python con le opzioni di ottimizzazione, -O. in
> quel caso crea dei file con bytecode ottimizzato .pyo, invece dei
> classici .pyc, inoltre è interessante come viene ottimizzato il codice:
>
>import dis
>
>def error(msg):
>if __debug__:
>print msg
>
>error('exception...')
>dis.dis(error)
>
> prova a lanciare questo codice prima normalmente e poi con l'opzione -O.
>

Wow! Sinceramente ci speravo in una variabile tipo quella, anche se non ci
contavo troppo, a questo punto potrei usufruire della variabile __debug__,
visto che ottimizza anche il bytecode finale. Ho provato a ripetere
l'esempio con una variabile booleana "debug" e in nessun caso il codice
viene ottimizzato.
Mi sembra un ottimo compromesso aggiungere una semplice opzione -O per
ottenere un insieme di benefici.
L'opzione è da ripetere ad ogni esecuzione o basta la prima volta lasciando
poi i .pyo? (a me comunque non ha salvato alcun .pyo, magari lo farà quando
lo chiamano altri moduli)

Grazie ancora!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Criptazione dei file sorgenti per evitare la manomissione

[lex mlist]

Beh, sperando che rimanga cosi... supporta solo python 2.5 e python2.6, io
mi stò già appoggiando a Python3 direttamente.

Lo sò che non è una soluzione al problema unpyc che prima o dopo ci arriverà
(magari già è in sviluppo), comunque ripeto, non è che ci sia da difendere
chissà che in termini di proprietà intellettuale, una eventuale
decompilazione non espone a rischi di natura pecuniaria, ma dovrebbe servire
semplicemente da dissuasore per le modifiche, poi se qualcuno ha voglia di
farsi tutto quello, beh...

Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente
decompilabile, hai quindi una qualche alternativa?
oppure un programma python è destinato a rimanere open source!?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Problema con la condivisione e l'utilizzo di un dict globale

[lex mlist]

Giorno,

torno alla carica con un'altro problema (e chiedo scusa se vi stresso).

Ho una semplice applicazione di test, che sfrutta pyyaml per ricavare delle
informazioni da un file di configurazione.
Il modulo è cosi composto:
/
/setup.py
/mod/application.py
/mod/errors.py
/mod/__init__.py
/tests/test_1.py

application.py definisce una classe Application con il metodo setup e un
dict() (configuration) che deve contenere i dati caricati con pyyaml [1]
errors.py invece ha bisogno di accedere al dizionario configuration per
ricavare delle informazioni tipo lo stato del debug etc etc [2]
#2 è veramente banale, ma è solo a fini di test

in test_1 invece semplicemente all' if __name__ == "__main__": chiamo prima
la classe Application specificando il nome del file di configurazione, e poi
provo a chiamare la funzione Error ma risulta sempre falsa.
Provando a stampare con un print il dizionario (come si vede nella classe
Application) il dizionario fornisce tali coppie ti chiave valore.
A me sembra che il file errors.py utilizzi il dizionario prima della
modifica della classe Application.

Cosa sbaglio esattamente?

Grazie a tutti.

[1] http://paste.pocoo.org/show/290779/
[2] http://paste.pocoo.org/show/HEZfL1gfgNRLUq42MB14/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Criptazione dei file sorgenti per evitare la manomissione

[lex mlist]

Grazie sia a Daniele che a Marco per le risposte :)

Non mi devo preoccupare di hacking sui sorgenti, tanto gira e rigira un modo
chi è determinato lo trova sempre, e poi dovrei fare anche l'obfuscation del
codice macchina prodotto dalla compilazione in C, e non mi serve.
Penso che l'idea di distribuire il solo bytecode sia sufficiente,
l'importante è "tamponare" l'utente che vede il file di testo e pensa di
guardarlo/modificarlo senza sapere quel che stà facendo.
Ho già provato a includere l'interprete di Python e non mi sembra una cosa
affatto difficile!
Ci sono proprio tutti gli strumenti necessari, io mi stò studiando un po'
l'architettura di python per interesse personale, ma trovo che anche senza
saperne un tubo sia fattibile scrivere con le Python C/API.
(e quindi immagino che Lua sia davvero semplice da incorporare)


Il giorno 13 novembre 2010 01:04, Daniele Varrazzo  ha
scritto:

>
> PyInstaller fornisce anche supporto per creare un unico bundle che
> contiene sia l'eseguibile che i .pyc delle librerie che servono (e i
> .so/.dll). Probabilmente è facile modificarlo per fargli creare un bundle
> con l'eseguibile che vuoi tu invece dell'interprete Python., magari lo fa
> già...
>
> Ciao!
>

Gli darò un'occhiata, grazie per la segnalazione!

Vediamo un po' cosa riesco a fare...
questo Python mi piace sempre di più =))
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Criptazione dei file sorgenti per evitare la manomissione

[lex mlist]

Il giorno 12 novembre 2010 21:11, Raffaele Salmaso <
raffaele.salm...@gmail.com> ha scritto:

> Ni, py ha molte più librerie pronte, lua è molto più parco di risorse e
> molto più semplice da includere in un programma c. Dipende dagli usi
> (molti giochi usano lua e non python per implementare la logica)
>

Si infatti sono a conoscenza del fatto che molti videogame usino lua, e non
solo i videogame, per questo l'avevo messo tra le possibiltà.
Esattamente che cosa intendi con "lua è molto più parco di risorse"?


> Sinceramente. Non distribuirlo.
>
> Fallo client-server, sposta la logica in rete.
>

Uhm, in termini pratici il programma a runtime dovrebbe prendere attraverso
la rete i file (.py) necessari e leggerli?


> Se invece non vuoi/puoi, se vuoi semplicemente evitare che un appena
> appena intraprendere hakaro giochi con i tuoi file, prendili e compilali
> dentro un file c, e falli caricare dall'interprete.
>

Beh diciamo che il mio fine ultimo è quello di evitare i .py modificabili
con la criptazione per evitare che un semplice editor hex possa permettere
di leggerlo. Se poi l'utente ha voglia di farsi del reverse engineering,
studiarsi il flusso del programma e generare dei file alternativi, beh la
vedo dura, perchè davvero dovrebbe conoscere la chiave di crittazione,
dovrebbe sapere ogni file .py quali funzioni deve esporre e tante altre
variabili, e poi non mi preoccupo certo di quel livello, alla fine il gioco
non ne vale la candela.

Grazie mille per la tua risposta, ciao!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Criptazione dei file sorgenti per evitare la manomissione

[lex mlist]

Sera a tutti.

Pensavo di incorporare l'interprete di python in un mio progetto C, visto
che ho bisogno di permettere ad alcuni non-sviluppatori di sviluppare
facilmente le loro idee.
La scelta pende totalmente su di me, ero indeciso tra Python e LUA, ma
sebbene LUA lo conosco solo di vista, mi sembra che python sia più completo,
almeno in termini di package già pronti (se sbaglio vi prego di
correggermi).

Avrei però la necessità di produrre per la release del programma un sistema
di "protezione" per evitare che l'utente possa modificare i sorgenti di
python e compromettere il flusso di esecuzione del programma. Probabilmente
la risposta sarebbe "non dovresti usare python", ma scrivere un interprete
porta via troppo tempo e sinceramente non mi và di usare altri linguaggi
visto che quasi sempre sono per uno specifico scopo e non general purpose.
Pensavo di crittare il file con Rijndael e di scrivere quindi su un file
binario, e a runtime decrittare, e passare il file in memoria "in chiaro"
all'interpete.
Come sistema pensavo potesse andare (se avete esperienze e volete
condividerle sono tutt'orecchie), ma poi ho pensato che se uno di questi
sorgenti include un'altro modulo, sorgerebbero problemi perchè python
cercerebbe un python ".py" in chiaro e non lo troverebbe.

Avete da proporre qualche soluzione/workaround per questo problema?
Avete esperienze da porre alla mia attenzione per venire a conoscenza dei
reali problemi di una tale soluzione?

Grazie a tutti,
ciao e buona serata.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Quoting [was: Problema installazione package con setup.py]

[lex mlist]

Il giorno 05 novembre 2010 18:29, Daniele Varrazzo  ha
scritto:

> Intanto benvenuto, e grazie per *non* aver top-quotato, come l'interfaccia
> di gmail invita a fare :)
>

Grazie per il benvenuto, niente di che riguardo il quoting, anche io non
sono amante dei messaggi che quotano per intero tutto all'inizio o alla
fine.

Non c'è un codice per questo, ma quotare serve a creare un contesto,
> quindi se messaggi precedenti nel thread aiutano a chiarire di cosa si
> parli li puoi anche includere; come anche, del messaggio a cui rispondi e
> dei precedenti, sentiti libero di eliminare le parti che sono finite fuori
> argomento (non allo scopo di stravolgere il messaggio originale
> ovviamente!) Se poi mantieni l'attribuzione dei messaggi "sopravvissuti" ai
> vari autori, e magari cambi il titolo del messaggio quando si cambia
> argomento, allora sei un grande! :D
>
> Insomma, tipo questa risposta dovrebbe andare bene a tutti i nitpicker che
> girano per questa lista... :)


Perfetto, grazie mille per le dritte, cercherò di impegnarmi al massimo per
rispettare queste regole di buona convivenza :)

A presto!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Problema installazione package con setup.py

[lex mlist]

>
>
>from func import inutile
>inutile.inutile()
>
> Generalmente il nome del package principale corrisponde in qualche
> maniente al nome della distribuzione, per esempio Twisted ha il package
> principale che si chiama ``twisted``, questo per creare meno confusione.
>

Ah! capito, che errore stupido :-/
Beh allora mi sfugge l'utilità di dare un nome al package :/
Serve solo per quando il package viene distribuito tramite PyPI?


PS. ne approfitterei per chiedervi una cosa OT: rispondendo al messaggio
della ML è buona norma includere sia la mail della persona a cui rispondiamo
che la ML o solo la ML? Io uso mail.google.com per leggere le mail e mi
include automaticamente ambedue le mail, è un problema?

Di nuovo,
grazie :)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Problema installazione package con setup.py

[lex mlist]

Buongiorno a tutti,

sono nuovo della ML e pertanto ne approfitto per salutare tutti gli
iscritti.

Ho iniziato da poco con Python (dopo esperienze con altri linguaggi di
programmazione, principalmente C e C++).

Oggi, avendo del tempo a disposizione, stò provando a fare un semplice
package e ho iniziato dal setup.py.
La distribuzione del mio package è molto semplice:
=
root /
  setup.py
  + func/
   + __init__.py
   + inutile.py
=
Il file setup.py contiene [1] e il file inutile.py contiene questa semplice
funzione [2].

Lancio il file setup.py con l'opzione "develop" e tutto sembra andare a buon
fine, ma quando apro l'interprete interattivo (non ho ancora creato un
virtualenv, ma appena risolvo lo farò se riesco a farlo funzionare con
python3), e scrivo "import miomodulo" ottengo un importerror: no module
named miomodulo

Come mai?
Ho seguito diverse guide trovate sul web, e la cosa strana è che non ci sono
errori... il file __init__.py è vuoto.

[1] http://paste.pocoo.org/show/HVkOu7R0HiZPHmSOL5y9/
[2] http://paste.pocoo.org/show/7hJHptL5WL3Er6yu8PR3/

Grazie mille in anticipo, e scusate se è un argomento che magari trattate
migliaia di volte, ma mi sembra strano come fatto :(
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python