Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-16 19:40 GMT+01:00 Roberto De Ioris : > [...] > > Le alternative che *io* vedo sono tutte architetturali, ovvero mettersi > > nell'ordine di idee di avere un pool di worker fuori dall'app web e > > delegare quasi ogni cosa li. > > > Che sono le stesse che propongo io, django riceve la richiesta, fa tutti i > controlli del caso (come l'autenticazione) e poi passa la connessione (o > tramite proxy o tramite fd-passing su socket unix) al backend gevent che > continua a gestire la sessione liberando django. > > Forse mi sono perso qualcosa, ma quale è la differenza tra questa soluzione ed avere Apache prefork con N + M processi? La soluzione che hai indicato è quella tipica frontend + backend, nel caso in cui il frontend sa gestire 10K ma il backend no (e spesso non deve farlo). Ma davvero ci sono vantaggi in un ulteriore livello, in cui l'applicazione Django minimale fa da frontend e tutto il resto (inclusa connessione al database) la fa un ulteriore backend? Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] [OT] Nuovo sito python.org
Noto con piacere che hanno rifatto il trucco al sito web python.org Che ne pensate? :-) ps. magari è così da mo' ... .m .Massimo .Capanni σπευδε βραδεως ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] [OT] Nuovo sito python.org
2014-03-17 11:15 GMT+01:00 Massimo Capanni : > Noto con piacere che hanno rifatto il trucco al sito web python.org > Che ne pensate? > Muy lindo! Me gusta mucho màs! Carlos -- Coloro che sognano di giorno sono uomini pericolosi, perche' sono capaci di recitare a occhi aperti il loro sogno fino a renderlo possibile. Ed e' questo che feci anch'io. - (T.E. Lawrence) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
> 2014-03-16 19:40 GMT+01:00 Roberto De Ioris : > >> [...] >> > Le alternative che *io* vedo sono tutte architetturali, ovvero >> mettersi >> > nell'ordine di idee di avere un pool di worker fuori dall'app web e >> > delegare quasi ogni cosa li. >> >> >> Che sono le stesse che propongo io, django riceve la richiesta, fa tutti >> i >> controlli del caso (come l'autenticazione) e poi passa la connessione (o >> tramite proxy o tramite fd-passing su socket unix) al backend gevent che >> continua a gestire la sessione liberando django. >> >> Forse mi sono perso qualcosa, ma quale è la differenza tra questa > soluzione ed avere Apache prefork con N + M processi? > > La soluzione che hai indicato è quella tipica frontend + backend, nel caso > in cui il frontend sa gestire 10K ma il backend no (e spesso non deve > farlo). > > Ma davvero ci sono vantaggi in un ulteriore livello, in cui l'applicazione > Django minimale fa da frontend e tutto il resto (inclusa connessione al > database) la fa un ulteriore backend? > Ti faccio l'esempio di un progetto sui cui ho lavorato di recente che deve fornire notifiche (tramite SSE) in tempo reale, scrivendo dei testi in un div. La parte SSE all'inizio deve essere comunque autenticata, deve prendere dei dati dal db per scegliere che tipo di informazioni mi servono, dopo di che django non serve piu', i dati che mi arrivano sono presi da redis. Quindi una volta che django ha autenticato l'utente, e scelto cosa fargli vedere, passa la connessione (la tecnica usata e' irrilevante) al livello "back-backend" (chiamiamolo cosi') che si occupa di leggere in maniera non bloccante da una coda redis e inviare le informazioni (e la cosa potrebbe durare ore). A questo punto django ha finito il suo ciclo di richiesta ed e' pronto a gestirne un' altra. Il giro e' proxy non bloccante -> application server bloccante -> application server non bloccante. Non parlerei di vantaggi, ma di necessita', far digerire a django il modello gevent (o quello che sia) e' talmente tedioso come processo che tanto vale aggiungere un ulteriore strato. E' un po' piu' macchinoso senza dubbio, ma non ha (teoricamente) sorprese sul medio e lungo termine. Io non metto in dubbio che avere tutto non bloccante da cima a fondo sia l'approccio migliore, ma una azienda che ha investito in Django non passa a tornado da un giorno all'altro (o a nodejs o a Go o a Rust ecc. ecc.), quindi bisogna ricorrere a workaround che comunque mantengano un certo di grado di solidita'. (e poi devo ancora trovarne di framework non-blocking-friendly che siano al livello di django) Poi se alcune aziende ci riescono, buon per loro, hanno il mio rispetto e la mia somma invidia :) -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-15 7:42 GMT+01:00 Nicola Larosa : > Manlio Perillo wrote: > >> > [...] > > Twisted offre un framework per la programmazione asincrona da anni, >> ma non è mai stato di moda, perchè molto più difficile. >> > > Non ha avuto grande successo per vari altri motivi: avanti sui suoi > tempi, documentazione carente, e anche insistenza sulla sintassi a > callback preferita alle inline callback. > > Secondo me molto ha influito il fatto che non fosse compatibile con il resto del mondo Python. > > > Considerato tutti i problemi che gli utenti hanno con tornado e >> friends (e che nemmeno sanno di sapere), direi che, come sempre, >> "explicit is better than implicit". >> > > Poco ma sicuro. Creare punti impliciti di cambio di contesto, come fanno > gevent ed eventlet, e come fanno i thread preemptive, è ingestibile. > > Si, ma con gevent i punti di cambio di contesto sono "deterministici". Non sono espliciti, ma se la libreria che usa le coroutine è scritta bene sai dove può avvenire lo switch, anche se magari sommerso tra 5-10 funzioni (cosa non bella, in effetti, ma è proprio uno dei "problemi" con yield che ti devi portare dietro sempre) > > Il mio suggerimento è sempre quello di imparare prima le basi (vicino >> a quello che realmente succede) e solo dopo utilizzare cose che >> rendono la programmazione e manutenzione più semplice. >> > > Se con questo intendi passare per la sintassi a callback prima di usare > la pseudo sincrona, non sono d'accordo. No, indendevo capire quello che succede "sotto il cofano", altrimento non ci si rende conto dei possibili problemi e/o come risolverli. > Non si tratta di basi, è > semplicemente un modo diverso, molto meno leggibile, di scrivere codice > asincrono. > > Ormai le Promises ci sono anche in Javascript, non ha senso insistere col > vecchio modello. Però andare troppo oltre e rinunciare agli yield, che > marcano i punti di cambio di contesto, significa andarsela a cercare. > > Glyph Lefkowitz, cioè Mr. Twisted, fa un'ottima panoramica delle opzioni > disponibili, ed illustra bene i pericoli di usare una sintassi implicita: > > "1. Straight callbacks: Twisted’s IProtocol, JavaScript’s on idiom, > where you give a callback to something which will call it later and then > return control to something (usually a main loop) which will execute > those callbacks, > > 2. “Managed” callbacks, or Futures: Twisted’s Deferred, JavaScript’s > Promises/A[+], E’s Promises, where you create a dedicated > result-that-will-be-available-in-the-future object and return it for the > caller to add callbacks to, > > 3. Explicit coroutines: Twisted’s @inlineCallbacks, Tulip’s yield from > coroutines, C#’s async/await, where you have a syntactic feature that > explicitly suspends the current routine, > > 4. and finally, implicit coroutines: Java’s “green threads”, Twisted’s > Corotwine, eventlet, gevent, where any function may switch the entire > stack of the current thread of control by calling a function which > suspends it. > > Go non ha una sintassi per sospendere esplicitamente una goroutine; quindi appartiene a 4) ? > [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Nicola Larosa wrote: "3. Explicit coroutines: Twisted’s @inlineCallbacks, Tulip’s yield from coroutines, C#’s async/await, where you have a syntactic feature that explicitly suspends the current routine, 4. and finally, implicit coroutines: Java’s “green threads”, Twisted’s Corotwine, eventlet, gevent, where any function may switch the entire stack of the current thread of control by calling a function which suspends it." Manlio Perillo wrote: Go non ha una sintassi per sospendere esplicitamente una goroutine; quindi appartiene a 4)? La sospensione avviene quando una goroutine manda un valore su un canale non bufferizzato: fin quando un'altra goroutine non legge quel valore, la prima è bloccata. E poi ovviamente anche quando una goroutine riceve un valore da un canale non bufferizzato, o vuoto. Invio e ricezione fanno parte della sintassi del linguaggio, tramite gli operatori freccia "->" e "<-". -- Nicola Larosa - http://www.tekNico.net/ A plus sign is just a square with collapsed sides, after passing through a hash sign: ◽ # + (Where are my medications when I need them?) - Nicola Larosa, February 2014 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] [OT] Nuovo sito python.org
Secondo me è un bel restyling che ci voleva. Quella console in cui provare il codice Python direttamente dal browser mi ricorda tanto il modo in cui era strutturato il sito di Ruby fino a qualche mese fa. Adesso il sito di Ruby è cambiato, una volta aveva la paginetta di TryRuby in bella vista mentre ora c'è un link da cliccare per arrivarci. Il giorno 17 marzo 2014 11:15, Massimo Capanni ha scritto: > Noto con piacere che hanno rifatto il trucco al sito web python.org > Che ne pensate? > ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
On Mon, Mar 17, 2014 at 12:34 PM, Nicola Larosa wrote: > Nicola Larosa wrote: >> >>> "3. Explicit coroutines: Twisted’s @inlineCallbacks, Tulip’s yield >>> from coroutines, C#’s async/await, where you have a syntactic >>> feature that explicitly suspends the current routine, >>> >>> 4. and finally, implicit coroutines: Java’s “green threads”, >>> Twisted’s Corotwine, eventlet, gevent, where any function may >>> switch the entire stack of the current thread of control by calling >>> a function which suspends it." >>> >> > Manlio Perillo wrote: > >> Go non ha una sintassi per sospendere esplicitamente una goroutine; >> quindi appartiene a 4)? >> > > La sospensione avviene quando una goroutine manda un valore su un canale > non bufferizzato: fin quando un'altra goroutine non legge quel valore, la > prima è bloccata. > > E poi ovviamente anche quando una goroutine riceve un valore da un canale > non bufferizzato, o vuoto. > > Invio e ricezione fanno parte della sintassi del linguaggio, tramite gli > operatori freccia "->" e "<-". > > > Si, ma una scrittuta/lettura su un canale possono essere "nidificate" all'interno di N funzioni. Non è' lo stesso di quello che accade con gevent? Con yield è diverso, perchè deve essere presente in ogni livello di chiamata a funzione. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Pyqt QtableWidget itemPressed(int,int)
Salve a tutti,
Sono da poco passato a PyQt e ho un problema con i signal. Ho una
QMainWindow che richiama un QDialog su cui è presente un QtableWidget. Il
tableWidget ha un signal, vedi sotto, che stampa riga e colonna dell'item
cliccato.
Siccome il QDialog e il QMainWindow sono in due file separati, aggiungendo
il codice sotto al file del QDialog non ho problemi e funziona tutto a
dovere.
File: TFT_Output_GUI.py
(...)
QtCore.QObject.connect(self.tableWidget,
QtCore.SIGNAL(_fromUtf8("cellPressed(int,int)")),
self.test)
QtCore.QMetaObject.connectSlotsByName(Dialog)
def test(self,row,column):
print row,column
(...)
if __name__ == "__main__":
import sys
app = QtGui.QApplication(sys.argv)
Dialog = QtGui.QDialog()
ui = Ui_Dialog()
ui.setupUi(Dialog)
Dialog.show()
sys.exit(app.exec_())
Quando invece lo vado a richiamare dal QMainWindow non viene mai triggerato
l'evento cellPressed e non entra nella funzione test.
A seguire il codice differente:
File: MyApp.py
class ResultDialog():
def __init__(self,parent=None):
self.Dialog = QtGui.QDialog(parent.MainWindow)
self.ui = TFT_Output_Gui.Ui_Dialog()
self.ui.setupUi(self.Dialog)
QtCore.QObject.connect(self.ui.tableWidget,
QtCore.SIGNAL(TFT_Output_Gui._fromUtf8("cellPressed(int,int)")),
self.test)
QtCore.QMetaObject.connectSlotsByName(self.Dialog)
self.Dialog.show()
def test(self,row,column):
print row,column
Qualche idea del perchè succeda?
--
Giuseppe Amato
e-mail: giuam...@gmail.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
2014-03-17 11:22 GMT+01:00 Roberto De Ioris : > > [...] > >> Forse mi sono perso qualcosa, ma quale è la differenza tra questa > > soluzione ed avere Apache prefork con N + M processi? > > > > La soluzione che hai indicato è quella tipica frontend + backend, nel > caso > > in cui il frontend sa gestire 10K ma il backend no (e spesso non deve > > farlo). > > > > Ma davvero ci sono vantaggi in un ulteriore livello, in cui > l'applicazione > > Django minimale fa da frontend e tutto il resto (inclusa connessione al > > database) la fa un ulteriore backend? > > > > Ti faccio l'esempio di un progetto sui cui ho lavorato di recente che deve > fornire notifiche (tramite SSE) in tempo reale, scrivendo dei testi in un > div. > > La parte SSE all'inizio deve essere comunque autenticata, deve prendere > dei dati dal db per scegliere che tipo di informazioni mi servono, dopo di > che django non serve piu', i dati che mi arrivano sono presi da redis. > > Quindi una volta che django ha autenticato l'utente, e scelto cosa fargli > vedere, passa la connessione (la tecnica usata e' irrilevante) Irrilevante, ma altamente dipendente dal sistema operativo e non tutti la supportano :) > al livello > "back-backend" (chiamiamolo cosi') che si occupa di leggere in maniera non > bloccante da una coda redis e inviare le informazioni (e la cosa potrebbe > durare ore). A questo punto django ha finito il suo ciclo di richiesta ed > e' pronto a gestirne un' altra. > > In effetti questo è un caso particolare che non avevo considerato. > Il giro e' > > proxy non bloccante -> application server bloccante -> application server > non bloccante. > > Non parlerei di vantaggi, ma di necessita', far digerire a django il > modello gevent (o quello che sia) e' talmente tedioso come processo che > tanto vale aggiungere un ulteriore strato. E' un po' piu' macchinoso senza > dubbio, ma non ha (teoricamente) sorprese sul medio e lungo termine. > > Questo non è un caso d'uso dei web sockets? Il problema è l'autenticazione; con la soluzione attuale il back-back-end riceve dati da una fonte sicura. Però con i websockets potresti disaccoppiare completamente i due backend (?). > Io non metto in dubbio che avere tutto non bloccante da cima a fondo sia > l'approccio migliore, ma una azienda che ha investito in Django non passa > a tornado da un giorno all'altro (o a nodejs o a Go o a Rust ecc. ecc.), > quindi bisogna ricorrere a workaround che comunque mantengano un certo di > grado di solidita'. (e poi devo ancora trovarne di framework > non-blocking-friendly che siano al livello di django) > > Vero, ma bisogna stare attenti a non cadere nella sindrome dell'utilizzo a tutti costi perchè è l'unica cosa che conosco/conoscono gli altri. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Non blocking http server e integrazione con database relazionali
Manlio Perillo wrote: Si, ma una scrittura/lettura su un canale possono essere "nidificate" all'interno di N funzioni. Non è lo stesso di quello che accade con gevent? Con yield è diverso, perchè deve essere presente in ogni livello di chiamata a funzione. Non l'avevo vista in questi termini, ma credo tu abbia ragione. -- Nicola Larosa - http://www.tekNico.net/ I still get as annoyed as ever by "use the right tool for the job" - the bland truism meant to shut down critical discussion and engagement with the tasks and choices in software engineering, replacing it with a weak passionless technical fatalism. - Ian Bicking, February 2014 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Escape stringa con char speciali
On 03/15/2014 11:45 AM, Enrico Bianchi wrote: > On 03/12/2014 04:23 PM, Fabrizio Soppelsa wrote: >> Ogni suggerimento ben accetto:) > > Perche` non ti connetti direttamente al database con il driver apposito? Perche' devo lavorare su una macchina che boota da PXE e non posso installare niente in piu' del sistema base. FS. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] alternative ad eval
Ho un array di tuple cosi formate da 3 elementi:
(int|float|boolean|string|datetime|..., string, boolean). Es:
[
(10, "value >= 1", True),
("Ciao", "o in value", True),
(True, "value == False", False),
(92.5f, "value >= 92.0f", True),
]
Il primo elemento della tupla può essere qualunque tipo o classe di python.
Il secondo elemento è una espressione da applicare sulla tupla e che deve
restituire True or False(value si riferisce al primo elemento della tupa)
Il terzo elemento è il risultato dell'operazione appena sopra.
A intervalli regolari ho bisogno di scorrere l'array sopra e aggiornare il
valore del terzo elemento.
Ho pensato di usare eval in questo modo:
def check_status(value, eval_string):
rc = eval(eval_string)
if rc is not bool: raise WrongEvalString()
return rc
Conosco i rischi di eval e vorrei evitare di usarlo però non riesco a
trovare nulla di altrettanto semplice e con le stesse potenzialità.
NB: In realtà la stringa che fa la validazione può essere impostata solo da
qualcuno di autorizzato quindi il rischio che mi cancelli tutto il fs non
ci dovrebbe essere, e non dovrebbero nemmeno fare operazioni del tipo
"value ** value" però in ogni caso vorrei trovare qualcosa che mi metta al
sicuro da questo tipo di operazioni.
grazie
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] alternative ad eval
2014-03-17 21:57 GMT+00:00 Balan Victor : > Conosco i rischi di eval e vorrei evitare di usarlo però non riesco a > trovare nulla di altrettanto semplice e con le stesse potenzialità. > La soluzione 'semplice' e' scrivere un piccolo parser per le espressioni che ti servono. E' meno complicato di quello che sembra, e' molto robusto perche' hai il completo controllo e non hai rischi. Altrimenti Python viene con un po' di librerie per parsare python. Il problema e' che una completa sandbox e' (l'ultima volta che mi ero informato) essenzialmente impossibile per come funziona Python. Quindi hai comunque rischi. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] alternative ad eval
Il giorno 17 marzo 2014 23:29, enrico franchi ha scritto: > > 2014-03-17 21:57 GMT+00:00 Balan Victor : > > Conosco i rischi di eval e vorrei evitare di usarlo però non riesco a >> trovare nulla di altrettanto semplice e con le stesse potenzialità. >> > > La soluzione 'semplice' e' scrivere un piccolo parser per le espressioni > che ti servono. > E' meno complicato di quello che sembra, e' molto robusto perche' hai il > completo controllo e non hai rischi. > > Ci avevo pensato però non ho trovato granché che mi aiutasse a fare qualche prova. Inoltre visto che l'utente, se ha bisogno, può definire oggetti di vario tipo per essere usati come value può anche definire una funzione check per l'oggetto e dentro la stringa da passare ad eval può scrivere "value.check()". Questo come lo gestisco nel parser? E come li passo value ? Questo è un caso estremo, però può accedere. I n ogni caso mi accontento di farlo funzionare solo con int, float, bool, string e datetime però non so da dove cominciare. > Altrimenti Python viene con un po' di librerie per parsare python. Il > problema e' che una completa sandbox e' (l'ultima volta che mi ero > informato) essenzialmente impossibile per come funziona Python. Quindi hai > comunque rischi. > tipo pyparser? L'ho guardato ma la documentazione non mi sembra molto chiara e sembra che sia stato abbandonato ... ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] alternative ad eval
2014-03-17 23:14 GMT+00:00 Balan Victor : > > Il giorno 17 marzo 2014 23:29, enrico franchi ha > scritto: > > >> 2014-03-17 21:57 GMT+00:00 Balan Victor : >> >> Conosco i rischi di eval e vorrei evitare di usarlo però non riesco a >>> trovare nulla di altrettanto semplice e con le stesse potenzialità. >>> >> >> La soluzione 'semplice' e' scrivere un piccolo parser per le espressioni >> che ti servono. >> E' meno complicato di quello che sembra, e' molto robusto perche' hai il >> completo controllo e non hai rischi. >> >> Ci avevo pensato però non ho trovato granché che mi aiutasse a fare > qualche prova. Inoltre visto che l'utente, se ha bisogno, può definire > oggetti di vario tipo per essere usati come value può anche definire una > funzione check per l'oggetto e dentro la stringa da passare ad eval può > scrivere "value.check()". Questo come lo gestisco nel parser? E come li > passo value ? Questo è un caso estremo, però può accedere. I > > In ogni caso mi accontento di farlo funzionare solo con int, float, bool, > string e datetime però non so da dove cominciare. > Ehm.. con la grammatica del linguaggio che vuoi parsare. Ma lascia che te lo dica... secondo me rischi di ficcarti in un mezzo ginepraio. Il fatto che tu abbia bisogno di questo secondo campo cosi' flessibile non ottimo indice che le cose saranno facili. Per il resto puoi definirti un linguaggio che fa tutto quello che ti pare, ma non sarebbe meglio limitarsi ad un set di check prefabbricati? > > > >> Altrimenti Python viene con un po' di librerie per parsare python. Il >> problema e' che una completa sandbox e' (l'ultima volta che mi ero >> informato) essenzialmente impossibile per come funziona Python. Quindi hai >> comunque rischi. >> > tipo pyparser? L'ho guardato ma la documentazione non mi sembra molto > chiara e sembra che sia stato abbandonato ... > No, quello ti serve per scrivere un parser. Uno dei tanti tool per farlo. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
