Re: [Python] web2py: lo conoscete - sessioni su db
On Tue, Dec 13, 2011 at 08:01:27PM +0100, Manlio Perillo wrote: Comunque ip_hash funziona solo se hai *un solo* server Nginx che accetta tutte le richieste e poi le rigira alle instanze di tornado. http://wiki.nginx.org/HttpUpstreamModule#ip_hash Hai idea di quanto dura la affinity? fino al restart di nginix? sandro *:-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete - sessioni su db
On Tue, Dec 13, 2011 at 08:01:27PM +0100, Manlio Perillo wrote: Visto che tu conosci bene nginix, ip_hash è totalmente affidabile per la session affinity?, abbiamo avuto alcuni comportamenti strani dopo avere attivato il setup con svariate istanze di tornado su 2 server che si risolvevano dirottando verso una seconda istanza di nginix con un solo server (e due tornado) non sono sicuro che fosse un problema di sessioni, ma il tarlo ce l'ho... Non sono sicuro di avere capito il setup dei server. credo che il fatto che tu non l'abbia capito dipenda dalla informazione che svia del secondo nginix che *non* fa parte del setup in produzione. La produzione ha una istanza di nginix come load balancer fra 10 processi su 2 macchine (porte differenti). Solo per test, un secondo nginix è stato abilitato come load balancer su 2 di questi processi su una sola macchina. sandro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete - sessioni su db
On Tue, 13 Dec 2011 00:42:59 +0100, Alessandro Dentella wrote: Comincio dal fondo, forse risulta più chiaro il tutto. On Mon, Dec 12, 2011 at 10:13:48PM +, Daniele Varrazzo wrote: A proposito, poi com'è andata con la storia di tornado e psycopg? bene! con 10 processi tornado i tempi si sono azzerati Ah, la soluzione se va bene a FriendFeed va bene anche a me :) ok. E perché vorresti impedire di leggere? Uno fa tanto per progettare un database che consenta letture e scritture concorrenti e tu infili gli un ombrello nella ruota davanti? :) come la metti giù dura! Quelli che fanno tutta quella fatica a progettare i db hanno anche pensato alla utilità del SELECT FOR UPDATE, quelli di postgresql poi l'hanno fatto selettivo al singolo record, ed in lettura mica mi si blocca se non uso FOR UPDATE. L'update della sessione lo blocco dove mi serve! Sì, ma il blocco serve a coordinare la scrittura consistente di diversi record: usare il lock per serializzare nel tempo è un noto anti-pattern sui database. Nel tuo caso, siccome vuoi applicarlo alle sessioni, il lock viene preso molto presto e rilasciato molto tardi nel tempo di vita di una richiesta, quindi stai effettivamente serializzando tutte le richieste di un utente, come tutte le chiamate ajax di una pagina. Quello che vorrei farti capire, ma non sono bravo è che c'è qualcosa che *puzza*. Avete un ambiente concorrente per definizione (diversi utenti contemporaneamente, diverse richieste per utente via ajax). Avete un framework concorrente (lasciamo perdere che è usato male: più viene usato meglio più lo diventa). Avete un database che supporta la concorrenza... e qual'è il problema: che è troppo concorrente?!?! E lo volete serializzare? Allora, non vedi che in questo disegno qualcosa non va? Da quello che descrivi, avete stato in memoria, stato in postgres, stato in redis, più le sessioni, e tutte devono essere coordinate... Mi sembra un grosso problema farlo. Perchè tutta questa isteria? Quanta roba ci dovete scrivere nelle sessioni, che le richieste ajax si inciampano a vicenda? Nella sessione scrivici l'id dell'utente e basta, lo scrivi al login e lo usi solo per leggere. Mi sembra di capire che ogni richiesta ci scriva qualcosa: perché lo scrivi nella sessione e non lo tieni in memoria o in redis? Controindicazioni dei lock espliciti? Quante ne vuoi. Non è una Dai dammene qualcuna di convincente... Googla database ipc antipattern. Diciamo che la prevedo così: se sei fortunato, noti immediatamente un rallentamento di prestazioni dovuto alla serializzazione di ogni richiesta. Se non lo sei, la serializzazione resta latente: a un certo punto ci sarà un cambiamento non collegato nelle richieste al database che litigherà coi lock presi sulla sessione e vi trovate con qualcosa che non cammina più, e se non avete sviluppato strategie di debug dei lock sul database, se non vi ricordate nemmeno che avete messo i lock sulle sessioni... in bocca al lupo a capire perché. Se hai richieste concorrenti che devono essere processate in serie, fallo in memoria, visto che stai già pagando il prezzo di avere session affinity e quindi una certa garanzia che tutte le rihcieste l'utente vadano sullo stesso server. Voi avete in pratica un programma web che dialoga con un application server: ormai, tieni la consistenza nel server. Almeno serializzi solo quello che ti serve, non tutte le richieste che mai passeranno per il web server e che non hanno bisogno di serializzazione. Altrimenti serializzi anche servire file statici o cazzate del genere. Questo è un esempio: immagino i file statici siano serviti dal web server, ma qualcos'altro che non necessita di essere serializzato, che non fa parte dello spreadsheet, di sicuro ci sarà, e se serializzi le sessioni anche quello prende il suo share di tempo esclusivo. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete - sessioni su db
On Tue, Dec 13, 2011 at 10:26:57AM +, Daniele Varrazzo wrote: On Tue, 13 Dec 2011 00:42:59 +0100, Alessandro Dentella wrote: Comincio dal fondo, forse risulta più chiaro il tutto. On Mon, Dec 12, 2011 at 10:13:48PM +, Daniele Varrazzo wrote: A proposito, poi com'è andata con la storia di tornado e psycopg? bene! con 10 processi tornado i tempi si sono azzerati Ah, la soluzione se va bene a FriendFeed va bene anche a me :) ok. E perché vorresti impedire di leggere? Uno fa tanto per progettare un database che consenta letture e scritture concorrenti e tu infili gli un ombrello nella ruota davanti? :) come la metti giù dura! Quelli che fanno tutta quella fatica a progettare i db hanno anche pensato alla utilità del SELECT FOR UPDATE, quelli di postgresql poi l'hanno fatto selettivo al singolo record, ed in lettura mica mi si blocca se non uso FOR UPDATE. L'update della sessione lo blocco dove mi serve! Sì, ma il blocco serve a coordinare la scrittura consistente di diversi record: usare il lock per serializzare nel tempo è un noto anti-pattern sui database. Nel tuo caso, siccome vuoi applicarlo alle sessioni, il lock viene preso molto presto e rilasciato molto tardi nel tempo di vita di una richiesta, quindi stai effettivamente serializzando tutte le richieste di un utente, come tutte le chiamate ajax di una pagina. Quello che vorrei farti capire, ma non sono bravo è che c'è qualcosa che *puzza*. Avete un ambiente concorrente per definizione (diversi utenti contemporaneamente, diverse richieste per utente via ajax). Avete un framework concorrente (lasciamo perdere che è usato male: più viene usato meglio più lo diventa). Avete un database che supporta la concorrenza... e qual'è il problema: che è troppo concorrente?!?! E lo volete serializzare? Allora, non vedi che in questo disegno qualcosa non va? Da quello che descrivi, avete stato in memoria, stato in postgres, stato in redis, più le sessioni, e tutte devono essere coordinate... Mi sembra un grosso problema farlo. Perchè tutta questa isteria? Non sono stati differenti, è sempre la stessa cosa (la sessione) che viene memorizzata o in ram o in redis o in postgres: voglio scegliere la soluzione più idonea per quel particolare tipo di applicazione. Lo stato in memoria non mi piace: non posso riavviare il server con serenità. Eliminata questa richiesta non ho neanche più la necessità della session affinity. Redis è stato introdotto per affrontare il problema di rallentamenti come storage per le sessioni ma come errata diagnosi, ora non è più necessario anche perché dalle mie prove (assolutamente primitive) non si guadagna nulla di interessante rispetto al db. E la velocità non è il problema in ogni caso. Quanta roba ci dovete scrivere nelle sessioni, che le richieste ajax si inciampano a vicenda? Nella sessione scrivici l'id dell'utente e basta, lo scrivi al login e lo usi solo per leggere. Mi sembra di capire che ogni richiesta ci scriva qualcosa: perché lo scrivi nella sessione e non lo tieni in memoria o in redis? che vantaggio mi darebbe tenerlo in redis? Se hai richieste concorrenti che devono essere processate in serie, fallo in memoria, visto che stai già pagando il prezzo di avere session affinity e quindi una certa garanzia che tutte le rihcieste l'utente vadano sullo stesso server. Voi avete in pratica un programma web che dialoga con un application server: ormai, tieni la consistenza nel server. Almeno serializzi solo quello che ti serve, non tutte le richieste che mai passeranno per il web server e che non hanno bisogno di serializzazione. Altrimenti serializzi anche servire file statici o cazzate del genere. Questo è un esempio: immagino i file statici siano serviti dal web server, ma qualcos'altro che non necessita di essere serializzato, che non fa parte dello spreadsheet, di sicuro ci sarà, e se serializzi le sessioni anche quello prende il suo share di tempo esclusivo. ma anche se prendo le sessioni da db posso serializzare solo quello che mi serve. Al di fuori della pagina che simula il foglio elettronico non ho alcun bisogno di serializzare e lo evito. session affinity e quindi una certa garanzia che tutte le rihcieste tu qui dici una *certa* garanzia. Non so se esprime il fatto che la session affinity possa non essere garantita, io uso ip_hash di nginix ora... sandro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete - sessioni su db
On Tue, Dec 13, 2011 at 03:16:49PM +0100, Manlio Perillo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 13/12/2011 14:38, Alessandro Dentella ha scritto: [...] Non sono stati differenti, è sempre la stessa cosa (la sessione) che viene memorizzata o in ram o in redis o in postgres: voglio scegliere la soluzione più idonea per quel particolare tipo di applicazione. Lo stato in memoria non mi piace: non posso riavviare il server con serenità. Eliminata questa richiesta non ho neanche più la necessità della session affinity. Redis è stato introdotto per affrontare il problema di rallentamenti come storage per le sessioni ma come errata diagnosi, ora non è più necessario anche perché dalle mie prove (assolutamente primitive) non si guadagna nulla di interessante rispetto al db. Davvero? Mi aspetto che, per delle semplici sessioni (storage key-value) redis sia significativamente più veloce di un database relazionale. Lo è, ma stiamo parlando di numeri molti piccoli per le mie esigenze. Recuperare una sessione 'media' da pg mi prende 1.0 ms, recupararla da redis può prendere anche 5/6 volte meno. Se la sessione è grande l'unpickle prende oltre i 20 ms, quindi l'ottimizzazione non è certo da cercare in redis ma in una ottimizzazione di ciò che sta nella sessione. E la velocità non è il problema in ogni caso. Quanta roba ci dovete scrivere nelle sessioni, che le richieste ajax si inciampano a vicenda? Nella sessione scrivici l'id dell'utente e basta, lo scrivi al login e lo usi solo per leggere. Mi sembra di capire che ogni richiesta ci scriva qualcosa: perché lo scrivi nella sessione e non lo tieni in memoria o in redis? che vantaggio mi darebbe tenerlo in redis? Accesso ragionevolmente efficiente ed atomico + consistenza dei dati. Inoltre non hai il problema della session affinity. io intendevo rispetto al db non rispetto alla RAM Ti resta da decidere se usare PostgreSQL o Redis. Esatto, ed io propendo per pg. Prima che Daniele mi massacrasse sulla questione del select for update la preferivo anche per la possibilità di scegliere che alcune sessioni le prendo garantendo la sequenzialità (quelle che servono la spreadsheet). Ora ci rifletterò e se anche dovessi scegliere la strada della perdizione mi sa che non lo dico in lista :-) Le sessioni come sono strutturate? confesso che ne so ancora poco. Ho preso in mano questa situazione da un paio di settimane ma non a tempo pieno e altre cose hanno reclamato la mia attenzione. Chiaramente, per i motivi di cui sopra varrà la pena analizzare. Visto che tu conosci bene nginix, ip_hash è totalmente affidabile per la session affinity?, abbiamo avuto alcuni comportamenti strani dopo avere attivato il setup con svariate istanze di tornado su 2 server che si risolvevano dirottando verso una seconda istanza di nginix con un solo server (e due tornado) non sono sicuro che fosse un problema di sessioni, ma il tarlo ce l'ho... sandro *:-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete - sessioni su db
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 13/12/2011 18:51, Alessandro Dentella ha scritto: [...] Redis è stato introdotto per affrontare il problema di rallentamenti come storage per le sessioni ma come errata diagnosi, ora non è più necessario anche perché dalle mie prove (assolutamente primitive) non si guadagna nulla di interessante rispetto al db. Davvero? Mi aspetto che, per delle semplici sessioni (storage key-value) redis sia significativamente più veloce di un database relazionale. Lo è, ma stiamo parlando di numeri molti piccoli per le mie esigenze. Recuperare una sessione 'media' da pg mi prende 1.0 ms, recupararla da redis può prendere anche 5/6 volte meno. Se la sessione è grande l'unpickle prende oltre i 20 ms, quindi l'ottimizzazione non è certo da cercare in redis ma in una ottimizzazione di ciò che sta nella sessione. Valuta anche di testare alternative a pickle. Ad esempio http://msgpack.org/ (che non ho mai usato, comunque). [...] che vantaggio mi darebbe tenerlo in redis? Accesso ragionevolmente efficiente ed atomico + consistenza dei dati. Inoltre non hai il problema della session affinity. io intendevo rispetto al db non rispetto alla RAM Per semplici sessioni è più semplice di un database relazionale, IMHO. Inoltre: http://redis.io/topics/transactions WATCH usa un lock ottimistico, magari può essere una alternativa valida al problema che devi risolvere (che, devo ammettere, non sono ancora sicuro di aver capito pienamente). [...] Visto che tu conosci bene nginix, ip_hash è totalmente affidabile per la session affinity?, abbiamo avuto alcuni comportamenti strani dopo avere attivato il setup con svariate istanze di tornado su 2 server che si risolvevano dirottando verso una seconda istanza di nginix con un solo server (e due tornado) non sono sicuro che fosse un problema di sessioni, ma il tarlo ce l'ho... Non sono sicuro di avere capito il setup dei server. Comunque ip_hash funziona solo se hai *un solo* server Nginx che accetta tutte le richieste e poi le rigira alle instanze di tornado. http://wiki.nginx.org/HttpUpstreamModule#ip_hash Ciao Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7noQcACgkQscQJ24LbaURjOgCcDlUyTNmYMy8Vi7ire2c5k0e3 YVMAoJE0BfqHDn7ZP5EDU35Onp0StsTk =p21v -END PGP SIGNATURE- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete - sessioni su db
On Fri, Dec 02, 2011 at 03:37:34PM +, Daniele Varrazzo wrote: Ah, cherrypy è multithread, ma lo storage su file delle sessioni non è thread safe, me lo sono dovuto scrivere io. Mi chiedevo come mai l'autore originale del programma usasse memcached solo per salvare (si fa per dire le sessioni). Quando abbiamo fatto il multi-nodo, un mio collega ha visto lo storage delle sessioni su database (che potrebbe servirci se volessimo scalare su diverse macchine) e ha detto che anche quello è finto. Nel cammino verso l'indipendenza dell'applicativo dal processo voglio portare le sessioni su database. Considerando che attualmente le singole request vengono evase in 100 ms circa, pensavo di farlo utilizzando SELECT FOR UPDATE, così da garantirmi che nessun'altra request possa leggere finché non ho evaso la request. Ci sono idee migliori o controindicazioni? (a parte che tengo occupata una connessione solo per questa transazione) Guadando il codice di django non ci leggo precauzioni contro questa eventualità, mi sfuggono o cherry-py non è solo? sandro *:-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete - sessioni su db
Comincio dal fondo, forse risulta più chiaro il tutto. On Mon, Dec 12, 2011 at 10:13:48PM +, Daniele Varrazzo wrote: A proposito, poi com'è andata con la storia di tornado e psycopg? bene! con 10 processi tornado i tempi si sono azzerati, la cpu continua a essere inutilizzata e la ram pure. La situazione attuale è quindi buona come performance ma bastarda nella natura (un server nato per essere usato in modo asyncrono e poi reso parallelo con differenti processi.) Personalmente sarei più contento di spostarlo su un altro framework, ma la scelta la faremo dopo avere analizzato cosa altro devono sviluppare. La session affinity è necessaria perché la sessione viene presa dalla RAM se esiste altrimenti da Redis, e salvata poi comunque su Redis. Il fatto di prenderla dalla RAM è odioso in quanto mi crea problemi a restartare il server, e presto cambierà. On Mon, 12 Dec 2011 18:49:38 +0100, Alessandro Dentella wrote: On Fri, Dec 02, 2011 at 03:37:34PM +, Daniele Varrazzo wrote: Ah, cherrypy è multithread, ma lo storage su file delle sessioni non è thread safe, me lo sono dovuto scrivere io. Mi chiedevo come mai l'autore originale del programma usasse memcached solo per salvare (si fa per dire le sessioni). Quando abbiamo fatto il multi-nodo, un mio collega ha visto lo storage delle sessioni su database (che potrebbe servirci se volessimo scalare su diverse macchine) e ha detto che anche quello è finto. Nel cammino verso l'indipendenza dell'applicativo dal processo voglio portare le sessioni su database. Uhm... ok... su file non vanno più bene? Assumo che lo vogliate fare per scalare oltre la singola macchina, altrimenti non c'è ragione. non sono su file, in questo momento sono... 1/2 in ram e 1/2 su Redis. Non si erano ancora resi conto che è bacato solo perché la usavano in modo sincrono e con un solo processo. Non trovo comoda la session affinity soprattutto in quanto non necessaria accettando il costo di qualche millisecondo per prendere e scrivere la session su db Considerando che attualmente le singole request vengono evase in 100 ms circa, pensavo di farlo utilizzando SELECT FOR UPDATE, così da garantirmi che nessun'altra request possa leggere finché non ho evaso la request. E perché vorresti impedire di leggere? Uno fa tanto per progettare un database che consenta letture e scritture concorrenti e tu infili gli un ombrello nella ruota davanti? :) come la metti giù dura! Quelli che fanno tutta quella fatica a progettare i db hanno anche pensato alla utilità del SELECT FOR UPDATE, quelli di postgresql poi l'hanno fatto selettivo al singolo record, ed in lettura mica mi si blocca se non uso FOR UPDATE. L'update della sessione lo blocco dove mi serve! Attualmente scrivono e se ne fregano, il risultato è che alcuni dati vengono sovrascritti, quindi se il controllo lo devo fare, tanto vale farlo prima, visto che esiste un modo così semplice. Il programma è una griglia che viene compilata, ad ogni cambio cella parte una richiesta ajax. La probabilità che uno si incespichi con sè stesso è comunque bassa, quindi non mi aspetto che si debbano perdere molti ms. Ci sono idee migliori o controindicazioni? (a parte che tengo occupata una connessione solo per questa transazione) Controindicazioni dei lock espliciti? Quante ne vuoi. Non è una buona idea. Sono pochi i problemi che hanno davvero bisogno di un lock per essere risolti, e tu non sei neanche sicuro di avere un problema: ti direi lascia perdere che rischi di fare più danni di quelli di cui hai bisogno. il problema c'è ed è tangibile Guadando il codice di django non ci leggo precauzioni contro questa eventualità, mi sfuggono o cherry-py non è solo? Forse semplicemente non è un problema. Se hai un burst di letture sullo stesso utente dovuto a richieste asincrone, dovrebbero leggere tutte uno stato consistente della sessione. I problemi di cherrypy non è così, leggono e cambiano la sessione, la successiva deve leggere i nuovi valori. Hanno voluto aspettare a salvare sul db per offrire una opzione di salvare o annullare e -per come è fatta ora la soluzione- lasciano in sessione un tot di dati. sono ridicolamente altri, secondo me django due o tre persone l'hanno testato e va bene così com'è. Con cherrypy a volte le (due o tre? allora le conosco tutte! ;-) sessioni leggevano un file e lo trovavano vuoto perché la richiesta di prima l'aveva aperto per scrivere (con open(name, 'w')) e non l'aveva ancora chiuso; con postgres questo problema non esiste: o il vecchio, o il nuovo, ma un record consistente ce lo trovi. Le ma se è vecchio non mi serve! allora meglio aspettare per avere il nuovo... Controindicazioni dei lock espliciti? Quante ne vuoi. Non è una Dai dammene qualcuna di convincente... sandro *:-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 02/12/2011 01:54, Daniele Varrazzo ha scritto: On Thu, 1 Dec 2011 22:25:09 +0100, Giorgio Zoppi wrote: che pensate di Cherrypy? Che sia maledetto lui e le sue variabili thread-local. Anche Django non scherza. Tempo fa avevo visto come implementava il supporto a i18n per la traduzione dei messaggi, e sono rabbrividito... Ciao Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7Y6F0ACgkQscQJ24LbaURVFwCeKgV062FSpH3IAdGzceEIkoRY 8BsAn267nPyrrqxyw2yu1Or6ObBkmYSa =Fqfw -END PGP SIGNATURE- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
On Fri, 02 Dec 2011 16:01:50 +0100, Manlio Perillo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 02/12/2011 01:54, Daniele Varrazzo ha scritto: On Thu, 1 Dec 2011 22:25:09 +0100, Giorgio Zoppi wrote: che pensate di Cherrypy? Che sia maledetto lui e le sue variabili thread-local. Anche Django non scherza. Tempo fa avevo visto come implementava il supporto a i18n per la traduzione dei messaggi, e sono rabbrividito... Sì, ma almeno non hai cherrypy.request che maggicamente restituisce la richiesta http del thread corrente, o cherrypy.session che restituisce la sessione dell'utente di quel thread. Ti ci voglio a debuggarlo... Anche se abbiamo un REPL in ascolto su una porta interna per il debug live, possiamo chiamare tutte le funzioni del programma... ma non quelle che usano qualunque oggetto cherrypy, perché il REPL gira in un thread a parte. Questo mettilo su url dispatcher inesistente (il primo segmento della url è la funzione invocata, gli altri argomenti posizionali). Una porcheria totale. Ci mantengo/estendo un programma da qualche anno e so quello che dico (è il programma della mail di prima). Ah, cherrypy è multithread, ma lo storage su file delle sessioni non è thread safe, me lo sono dovuto scrivere io. Mi chiedevo come mai l'autore originale del programma usasse memcached solo per salvare (si fa per dire le sessioni). Quando abbiamo fatto il multi-nodo, un mio collega ha visto lo storage delle sessioni su database (che potrebbe servirci se volessimo scalare su diverse macchine) e ha detto che anche quello è finto. Il supporto per l'i18n di Django non lo conosco bene, ma qualunque cosa sia ho sicuramente visto di peggio e su concetti molto più fondamentali, tipo richiama questa funzione con questa richiesta http. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
Il 30 novembre 2011 23:41, enrico franchi enrico.fran...@gmail.com ha scritto: Oltretutto non ne sento l'esigenza. [..] Poi ci sono i vari micro-framework per quando si vuole poca funzionalita', magari si fanno cose poco strutturate e strambe. Tipo a me a volte fanno comodo per mettere su robba che comando via pagine web ma che non ha la struttura di un sito, e' piu' una mini-ui su altro. Li meno ho, meglio e'. Potresti fare qualche esempio di micro-framework per favore ? Mi interessa l'argomento Grazie ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
Sebbene non l'abbia ancora usato stavo iniziando a vedere Flask. Mi sembra molto buono perchè si basa su un sistema di templating (Jinja 2) che permette di essere utilizzato anche con LaTeX, HTML, CSV, XML e via cantando. In pratica con uno strumento, in realtà, ne impari due :-) Gli altri non li conosco per nulla per cui non mi pronuncio... 2011/12/1 Marco Mariani bir...@gmail.com 2011/12/1 Francesco Maida d...@cesco.it Potresti fare qualche esempio di micro-framework per favore ? Mi interessa l'argomento In ordine alfabetico: Bottle, Flask, Pyramid, Werkzeug. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python -- Blog:http://zuccala.blogspot.com/ Twitter: http://twitter.com/#!/VittorioZuccala/ Buzz: http://www.google.com/profiles/nathanvi#buzz ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
2011/12/1 Marco Mariani bir...@gmail.com: 2011/12/1 Francesco Maida d...@cesco.it In ordine alfabetico: Bottle, Flask, Pyramid, Werkzeug. Una volta c'era anche web.py... e' ancora mantenuto? Poi credo che ne manchino... secondo recenti statistiche ogni programmatore python ha implementato almeno una volta nella vita un qualche tipo di micro-framework... :P -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
2011/12/1 enrico franchi enrico.fran...@gmail.com: 2011/12/1 Francesco Maida d...@cesco.it In ordine alfabetico: Bottle, Flask, Pyramid, Werkzeug. Poi credo che ne manchino... secondo recenti statistiche ogni programmatore python ha implementato almeno una volta nella vita un qualche tipo di micro-framework... :P Se cosi` fosse, il mercato di programmatori python sarebbe piu` inflazionato di quello java. Spero che ci sia almeno un rapporto 3:1 tra FW e pythonisti, altrimenti conviene cambiare lavoro. © -- Carlo Miron I Lower The Average Solution Architect™ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
2011/12/1 enrico franchi enrico.fran...@gmail.com Poi credo che ne manchino... Senza dubbio, sono andato a memoria secondo recenti statistiche ogni programmatore python ha implementato almeno una volta nella vita un qualche tipo di micro-framework... :P Un micro-framework _non_ e' un framework piccolo. Oltre che di dimensioni contenute, deve anche essere abbastanza flessibile da non rompere le palle quando vuoi cambiare template, orm, session manager, autenticazione, etc. etc. o anche scrivere i tuoi perche' ne hai bisogno o voglia. Il che non e' molto comune, purtroppo. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 01/12/2011 15:39, enrico franchi ha scritto: 2011/12/1 Marco Mariani bir...@gmail.com: 2011/12/1 Francesco Maida d...@cesco.it In ordine alfabetico: Bottle, Flask, Pyramid, Werkzeug. Una volta c'era anche web.py... e' ancora mantenuto? Poi credo che ne manchino... secondo recenti statistiche ogni programmatore python ha implementato almeno una volta nella vita un qualche tipo di micro-framework... :P Eccomi: http://hg.mperillo.ath.cx/wsgix/wsgix ;-) Non è proprio micro, comunque... Ciao Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7XokEACgkQscQJ24LbaUQcOgCfZXL2+JnRVQBKisJGatSbi2sI pIsAnR2wwny3hqS4YWLyyPr9iGGgcOHS =ojjW -END PGP SIGNATURE- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
Il giorno gio, 01/12/2011 alle 15.39 +0100, enrico franchi ha scritto: 2011/12/1 Marco Mariani bir...@gmail.com: 2011/12/1 Francesco Maida d...@cesco.it In ordine alfabetico: Bottle, Flask, Pyramid, Werkzeug. Una volta c'era anche web.py... e' ancora mantenuto? Ohibò, lo spero proprio, me lo sono imparato proprio due giorni fa (stufo di spippolare i cgi tutti a mano)... Un argomento più valido delle mie personali speranze è che l'ultima release è di luglio e la mailing list è dignitosamente attiva. Ma a parte ciò: (alcune del)le alternative analoghe (ovvero questi cosiddetti microframework) sono migliori? Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
Il 01 dicembre 2011 13:46, Marco Mariani bir...@gmail.com ha scritto: In ordine alfabetico: Bottle, Flask, Pyramid, Werkzeug. Grazie ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
2011/12/1 Marco Mariani bir...@gmail.com: 2011/12/1 enrico franchi enrico.fran...@gmail.com Poi credo che ne manchino... Senza dubbio, sono andato a memoria secondo recenti statistiche ogni programmatore python ha implementato almeno una volta nella vita un qualche tipo di micro-framework... :P Un micro-framework _non_ e' un framework piccolo. Era ovviamente una battuta! :) Tempo fa girava appunto questa battuta (specie relativo a templating + qualcosa su cgi/mod_python etc etc etc). E' stata solo aggiornata. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
che pensate di Cherrypy? Il 01 dicembre 2011 21:39, enrico franchi enrico.fran...@gmail.com ha scritto: 2011/12/1 Marco Mariani bir...@gmail.com: 2011/12/1 enrico franchi enrico.fran...@gmail.com Poi credo che ne manchino... Senza dubbio, sono andato a memoria secondo recenti statistiche ogni programmatore python ha implementato almeno una volta nella vita un qualche tipo di micro-framework... :P Un micro-framework _non_ e' un framework piccolo. Era ovviamente una battuta! :) Tempo fa girava appunto questa battuta (specie relativo a templating + qualcosa su cgi/mod_python etc etc etc). E' stata solo aggiornata. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python -- Quiero ser el rayo de sol que cada día te despierta para hacerte respirar y vivir en me. Favola -Moda. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
On Thu, 1 Dec 2011 22:25:09 +0100, Giorgio Zoppi wrote: che pensate di Cherrypy? Che sia maledetto lui e le sue variabili thread-local. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] web2py: lo conoscete ?
salve a tutti, leggendo in rete sui framework per python, ho trovato web2py. Lo conoscete ? Cosa ne pensate ? Aspetto vs suggerimenti/commenti. grazie. ciao ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] web2py: lo conoscete ?
2011/11/30 Riccardo mancuso mancuso.riccard...@gmail.com: leggendo in rete sui framework per python, ho trovato web2py. Lo conoscete ? Conoscere come so che esiste e lo ho guardato, si. Conoscere come ci ho lavorato, no. Cosa ne pensate ? Non ho la minima intenzione di lavorarci. Non vedo buoni motivi per farlo e molte delle scelte alla base non mi piacciono. Tipo quella di iniettare roba magica nel namespace globale. Oltretutto non ne sento l'esigenza. Mi sembra copra una nicchia inesistente. Django e' lo standard. Con i suoi pregi e i suoi difetti. Supporto grosso, community immensa, plugins, apps. Poi ci sono i vari turbogears e combriccola per chi vuole stare con SQLAlchemy (al momento non ho idea se sia stato finalmente portato su Django). Poi ci sono i vari micro-framework per quando si vuole poca funzionalita', magari si fanno cose poco strutturate e strambe. Tipo a me a volte fanno comodo per mettere su robba che comando via pagine web ma che non ha la struttura di un sito, e' piu' una mini-ui su altro. Li meno ho, meglio e'. Il fatto che possa leggere e comprendere *tutto* il codice in un oretta e' quasi un requisito, in questi casi. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
