Re: [Python] Gestione del tempo.
Ciao, On 19/12/13 15:41, Gabriele Battaglia wrote: [...] Progetto, sviluppare una piccola applicazione console, sotto Windows, con Python 2.7, che faccia da orologio per giocare a scacchi. La faccenda è presto detta: 2 timer partono da un tempo definibile dall'utente e scendono verso lo zero. Potrebbe essere divertente (e istruttivo) sviluppare l'applicazione come server e client per ogni giocatore... In questo modo volendo i due timer potrebbero anche essere su due macchine diverse. :) Lorenzo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] E' piu' forte di me
On 12/24/2013 12:37 AM, Giampaolo Rodola' wrote: 2013/12/23 Enrico Bianchi enrico.bian...@ymail.com mailto:enrico.bian...@ymail.com Ti diro`, non ho mai studiato (e mai studiero`) PHP, ma gia` il fatto che implementa l'operatore === per me e` motivo di evitarlo come la peste nera Quindi non gli bastava il fatto di poter usare = in una espressione. Hanno voluto aggiungere la possibilita' di creare nuovi e bellissimi bug :D Non posso fare a meno di riportare questo che ancora pervade il mio essere a distanza di anni dalla sua scoperta: php echo '2foo' + '5'; 7 Per chi non ci crede, è testabile qui: http://writecodeonline.com/php/ Ora, io non nutro il tuo stesso odio per PHP, però quando la luce emessa da '2foo' + '5' == 7 colpisce la mia rètina inevitabilmente il mio organismo si blocca per una manciata di secondi in cui mi passa tutta la vita davanti. PS: ovviamente php 'foo2' + '5' == 5 Complimenti anche per la scelta degli operatori. Mi sembra di capire che la concatenazione si faccia con il . (dot), e non solo per le stringhe: echo 3 . 4 + 4; Uno poco attento potrebbe pensare che il risultato sia 7.4. Eh no, occhio agli spazi! Il risultato e' 38. Deduco che per programmare in PHP sia necessario avere 11/10 di vista, ed essere molto molto attenti... Ma che pazzia e' questa! -- Marco Buttu INAF-Osservatorio Astronomico di Cagliari Via della Scienza n. 5, 09047 Selargius (CA) Phone: 070 711 80 217 Email: mbu...@oa-cagliari.inaf.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Deploy con nginx e proxy_pass
On Tue, Dec 24, 2013 at 09:19:19AM +0100, Roberto De Ioris wrote:
Ciao a tutti,
ho bisogno di capire una configurazione di un webs server nginx di un
cliente che usa proxy_pass passando come destinatario
upstream produzione {
server 127.0.0.1:8080;
server 127.0.0.1:8081;
...
}
proxy_pass http://produzione;
Quello che vorrei capire è come funziona e se è configurabile il
meccanismo
di assegnazione della richiesta ai vari server.
Il problema nasce dal fatto che hanno una applicazione fatta con tornado
ma
con chiamate non asincrone, ed una base di codice che si sono sviluppati
negli anni e che non hanno il coraggio/determinazione di cambiare.
il 99% delle funzioni prende meno di 1 secondo ma acunin prendono anche 10
secondi fino a 25 e questo è accettabile.
Il problema nasce dal fatto che in alcuni casi sperimentano dei blocchi.
La mia sensazione (e qui paleso la mia ignoranza in merito) è che nginx
faccia round robbin fra i 10 processi esistenti e non stia a guardare se
hanno terminato o meno la precedente richiesta. Esiste un modo di forzare
uno schema per cui vengano serviti solo i processi che non hanno in corso
una elaborazione?
NB: non esiste un problema di troppo carico, il server è sostanzialmente
sottosfruttato, il sito non ha un carico elevato
Sono graditi anche puntatori a letture illuminanti...
grazie
sandro
*:-)
___
Nelle release 1.3 di nginx puoi impostare il least connections come
algoritmo:
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#least_conn
grazie, leggo nella doc:
Specifies that a group should use a load balancing method where a request is
passed to the server with the least number of active connections, taking
into account weights of servers. If there are several such servers, they are
tried using a weighted round-robin balancing method.
ed immagino che le active connections siano esattamente quelle in
elaborazione. Considerando che ho 10 processi, il 99% delle richieste viene
espletato in meno di 1 secondo e ho un rate che nelle ore di punta arriva
a 2/secondo credo che sia molto probabile che ci sia sempre un processo
libero e che quindi questo venga scelto da questo algoritmo, se lo capisco
correttamente.
ma ho seri dubbi che il problema sia li', appena hai scritto tornado con
chiamate non asincrone, hai praticamente descritto IL problema ;)
Vero, ma questa è una eredità su cui non ho potere... per bypassarlo avevo
modificato il codice per potere girare con svariati (10 al momento) processi
indipendenti, ora è così ed in effetti la situazione è abbastanza gestibile
con l'eccezione dei blocchi descritti sopra.
io sono convinto che se il modello resta round robbin puro, anche se
raddoppiassi i processi avrei solo dimezzato la probabilità di incapare in
una chiamata lunga, mentre se potessi evitare di passare chiamate ad un
processo che sta lavorando eviterei proprio questa cosa.
aggancia una strace ai processi tornado durante un blocco per vedere che
succede. Probabilmente non ci sara' molto da fare se non aggiungere altri
processi tornado (sempre che sia tollerabile dall'applicazione).
le chiamate lunghe non sono chiamate che a random prendono tanto tempo, sono
chiamate che fanno molte cose probabilmente non ottimizzate, ma sulle
quali io non ho diretto controllo (sono inizializzazioni mensili di alcune
posizioni).
Grazie per il suggeriemnto
sandro
*:-)
--
Sandro Dentella *:-)
http://www.reteisi.org Soluzioni libere per le scuole
http://sqlkit.argolinux.orgSQLkit home page - PyGTK/python/sqlalchemy
sandro
*:-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Gestione del tempo.
Il giorno 24/dic/2013, alle ore 09:17, Lorenzo Sutton lorenzofsut...@gmail.com ha scritto: Potrebbe essere divertente (e istruttivo) sviluppare l'applicazione come server e client per ogni giocatore... In questo modo volendo i due timer potrebbero anche essere su due macchine diverse. :) GB: Ciao Lorenzo. Sì, divertente e utile, visto che organizziamo tornei di scacchi, sia italiani che internazionali, via Skype e dobbiamo sempre affidarci ad una terza persona per la gestione del tempo. Però un programma del genere va troppo al di là delle mie competenze. Per ora sto ancora cercando di farlo funzionare in locale :). Buone feste e grazie per la risposte. Gabriele. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] E' piu' forte di me
Il giorno 23 dicembre 2013 21:06, Gollum1 gollum1.smeag...@gmail.com ha scritto: Il 23/dic/2013 20:50 Carlos Catucci carlos.catu...@gmail.com ha scritto: [...] Regole: 1. Quark e' la particella elementare dell'universo. 2. Quark e' una trasmissione condotta Piero Angela. 3. Quark e' un formaggio svizzero. 30 minuti di elaborazioni e rispose che l'universo e' composto da formaggio svizzero ed e' gestirto da Piero Angela. Fine delle mie esperienze con il prolog. ;) Mitico... Ehehe prendere in giro le conclusioni assurde del prolog l'ho sempre trovato controproducente. Un programma in prolog rappresenta esattamente il modo di ragionare del programmatore in un contesto specifico, non a caso si usa, tra le altre cose, per creare sistemi esperti. Quindi, delle due una: o sei anche tu convinto che l'universo sia fatto di formaggio, oppure forse hai omesso/generalizzato della conoscenza sui quark indispensabile per fare ragionamenti corretti. In entrambi i casi il problema è il programmatore! :) Non so il borland, ma oggi credo che il prolog sia piuttosto veloce. Aggiungiamo anche che quei tre sono fatti e non regole e il cerchio è chiuso. ;) saluti, Gianluca ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Deploy con nginx e proxy_pass
io sono convinto che se il modello resta round robbin puro, anche se raddoppiassi i processi avrei solo dimezzato la probabilità di incapare in una chiamata lunga, mentre se potessi evitare di passare chiamate ad un processo che sta lavorando eviterei proprio questa cosa. aggancia una strace ai processi tornado durante un blocco per vedere che succede. Probabilmente non ci sara' molto da fare se non aggiungere altri processi tornado (sempre che sia tollerabile dall'applicazione). le chiamate lunghe non sono chiamate che a random prendono tanto tempo, sono chiamate che fanno molte cose probabilmente non ottimizzate, ma sulle quali io non ho diretto controllo (sono inizializzazioni mensili di alcune posizioni). Grazie per il suggeriemnto sandro *:-) Nginx non puo' farlo (vedi pero' nota sotto) L'approccio migliore (o meglio diciamo quello risolutivo) e' che i processi usino lo stesso socket, puoi provare il plugin tornado di uWSGI: http://uwsgi-docs.readthedocs.org/en/latest/Tornado.html ma non e' compilato di default (per motivi altamente tecnici: ovvero odio la programmazione callback based e non voglio incentivarla ulteriormente ;) anche gunicorn ha un worker model per tornado ma e' deprecato (ma presumo funzioni ancora) Nota: Se abbassi la listen queue del socket dentro tornado a 1 (in alcuni kernel puoi metterla anche a 0 che sarebeb addirittura meglio), otterrai subito un errore in caso di worker occupato e nginx passera' la richiesta al backend successivo. E' un buon trucco (anche se poco diffuso) nel tuo caso specifico. Altro approccio e' ridurre il proxy_connect_timeout, ma trovare il giusto compromesso sul valore e' dura -- Roberto De Ioris http://unbit.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] E' piu' forte di me
2013/12/24 Gianluca Esposito giae...@gmail.com Aggiungiamo anche che quei tre sono fatti e non regole e il cerchio è chiuso. ;) Dai era una cosa carina successa a suo tempo. Non ho nulla contro Prolog, anzi mi e' sempre stato simpatico. Solo che l'uso, come dici giustamente, richiede un approccio adeguato. Carlos -- Somos los que amasan, sin embargo no tenemos pan, somos los que cavan el carbón, sin embargo tenemos frío somos los que no tienen nada, y estamos viniendo a tomar el mundo. Tassos Livaditis (Poeta greco, 1922, 1988) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] E' piu' forte di me
Il giorno 24 dicembre 2013 12:23, Carlos Catucci carlos.catu...@gmail.comha scritto: 2013/12/24 Gianluca Esposito giae...@gmail.com Aggiungiamo anche che quei tre sono fatti e non regole e il cerchio è chiuso. ;) Dai era una cosa carina successa a suo tempo. Non ho nulla contro Prolog, anzi mi e' sempre stato simpatico. Solo che l'uso, come dici giustamente, richiede un approccio adeguato. Ho capito benissimo che era solo per la battuta, infatti ho messo tante faccine sorridenti :) ciao ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Sintassi.
On 21 December 2013 18:53, Simone Federici s.feder...@gmail.com wrote: Proponiamo una PEP 1 different 0 A me sembra piu' una PIP(pa mentale) ;) Carlos -- Somos los que amasan, sin embargo no tenemos pan, somos los que cavan el carbón, sin embargo tenemos frío somos los que no tienen nada, y estamos viniendo a tomar el mundo. Tassos Livaditis (Poeta greco, 1922, 1988) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Concorrenza differita (era: Re: Deploy con nginx e proxy_pass)
Roberto De Ioris wrote: odio la programmazione callback based Interessante, qui ci va una bella discussione sulla concorrenza. Solo che diversamente da voi che gozzovigliate, io sto ficcando casa dentro tanti scatoloni per il trasloco, quindi per me se ne riparla dopo l'epifania. Ma se intanto volete iniziare fate pure. ;-) -- Nicola Larosa - http://www.tekNico.net/ We need whistleblowers. We need to know exactly how the NSA and other agencies are subverting routers, switches, the Internet backbone, encryption technologies and cloud systems. I already have five stories from people like you, and I've just started collecting. I want 50. There's safety in numbers, and this form of civil disobedience is the moral thing to do. - Bruce Schneier, September 2013 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Concorrenza differita (era: Re: Deploy con nginx e proxy_pass)
Roberto De Ioris wrote:
odio la programmazione callback based
Interessante, qui ci va una bella discussione sulla concorrenza.
Solo che diversamente da voi che gozzovigliate, io sto ficcando casa
dentro tanti scatoloni per il trasloco, quindi per me se ne riparla dopo
l'epifania.
Ok,
#callback based:
def pluto():
print(fine);
def topolino():
wait_for('pluto', pluto)
def pippo():
wait_for('topolino', topolino)
wait_for('pippo', pippo)
# coroutine/greenthread/stackswitch/blah blah based:
wait_for('pippo')
pippo()
wait_for('topolino')
topolino()
wait_for('pluto')
pluto()
Personalmente trovo molto piu' leggibile la seconda forma (anche se
internamente l'implementazione e' piu' complessa) Se sei un fan di Go mi
darai regione (visto che e' come funzionano le goroutine) ;)
La prima la trovo molto comoda solo quando il nesting delle callback non
supera le 2 (quindi praticamente mai) e calcolando che e' la base di
funzionamento di node.js (che qui mentre blastate php diventa la nuova
preoccupante moda del momento con l'ultima conferenza che ha fatto 4k
persone) probabilmente sbaglio io :)
--
Roberto De Ioris
http://unbit.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] sfilza annuale di OOTO...
Il giorno 23 dicembre 2013 23:21, Simone Federici s.feder...@gmail.com ha scritto: Saluti a tutti e di più a chi è già in ferie! Tanti cari auguri a tutti voi e grazie per i regali che mi continuate a fare ogni giorno, visto che ogni discussione porta sempre qualcosa di nuovo (mi piace tanto tanto questa cosa). Gli ultimi giorni leggere la lista è quasi in lavoro visto il numero di messaggi, credo che la percentuale di feriati sia molto alta. ;-) Ciao e ancora auguri a tutti. Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Deploy con nginx e proxy_pass
On 24/12/2013 11:58, Roberto De Ioris wrote: [...] L'approccio migliore (o meglio diciamo quello risolutivo) e' che i processi usino lo stesso socket, puoi provare il plugin tornado di uWSGI: http://uwsgi-docs.readthedocs.org/en/latest/Tornado.html ma non e' compilato di default (per motivi altamente tecnici: ovvero odio la programmazione callback based e non voglio incentivarla ulteriormente ;) Eh, purtroppo l'approccio a callback con macchina a stati è l'unico possibile se vuoi portabilità ed efficienza. Rassegnamoci ;) [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Concorrenza differita (era: Re: Deploy con nginx e proxy_pass)
Roberto De Ioris wrote:
#callback based:
def pluto():
print(fine);
def topolino():
wait_for('pluto', pluto)
def pippo():
wait_for('topolino', topolino)
wait_for('pippo', pippo)
# coroutine/greenthread/stackswitch/blah blah based:
wait_for('pippo')
pippo()
wait_for('topolino')
topolino()
wait_for('pluto')
pluto()
Personalmente trovo molto piu' leggibile la seconda forma (anche se
internamente l'implementazione e' piu' complessa) Se sei un fan di Go mi
darai regione (visto che e' come funzionano le goroutine) ;)
Ti do ragione completamente. Anch'io trovo poco leggibile dover
saltellare per il codice alla ricerca di callback annidate o agganciate,
e la sintassi pseudosincrona permette di usare il modello a eventi
asincroni, unico modo per scalare tanto, senza doversi aggrovigliare
appresso alle callback.
Ai tempi di Twisted favorivo la sintassi pseudosincrona delle inline
callback a quella nativa, e questa è una delle tante cose che non mi
piacciono di Javascript. Se capisco bene, le promise sono un tentativo di
avere sintassi pseudosincrona anche lì.
E ci hai preso in pieno con l'accenno a goroutine e channel in Go. :-)
Anche in Tornado puoi avere la sintassi pseudosincrona usando
gen.coroutine, quindi magari puoi ripensare se includere di default il
relativo plugin in uWSGI. ;-)
(Gli scatoloni chiamano, ma non potevo non rispondere. :-) )
--
Nicola Larosa - http://www.tekNico.net/
We need whistleblowers. We need to know exactly how the NSA and other
agencies are subverting routers, switches, the Internet backbone,
encryption technologies and cloud systems. I already have five stories
from people like you, and I've just started collecting. I want 50.
There's safety in numbers, and this form of civil disobedience is the
moral thing to do. - Bruce Schneier, September 2013
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] E' piu' forte di me
Il giorno lun, 23/12/2013 alle 20.46 +0100, Balan Victor ha scritto: Il giorno 23 dicembre 2013 18:56, enrico franchi enrico.fran...@gmail.com ha scritto: 2013/12/23 Balan Victor balan.vict...@gmail.com tu parli da programmatore esperto e affermato, e li ti do ragione. Ora invece tira via il capellino del bravo programmatore(cit. Zaffanella) e mettiti quello dello studente delle superiori. Per la stragrande maggioranza degli studenti delle superiori è molto più facile partire da PHP invece che da Python! Victor, stai cercando di dimostrare che PHP e' più facile per partire *usando* il fatto che PHP è più facile. Guarda caso, non ero convinto che PHP fosse facile per partire allora e non lo sono ora. Era più facile per partire all'epoca!!! Django non esisteva nel 2004! Giusto perché nessuno ha ancora - mi pare - fatto notare questa ovvietà: per progetti che siano più complessi di un Hello world - quindi incluso il più semplice dei guestbook (magari con supporto utf-8), python addirittura in modalità cgi (quindi senza bisogno di Django, ma neppure di web.py/cherrypy/flask) è comunque più comodo del PHP (pensando a chi parte da zero in entrambi). Tutto ciò, chiaramente, al netto di lock-in dovuti alla scelta infelice di hosting. ciao Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] E' piu' forte di me
2013/12/23 Ranaridens i...@ranaridens.com dal PHP ho imparato quanto sia importante scrivere codice in modo chiaro ed utilizzare le classi. Nel senso in cui uno impara a scrivere buon codice da https://www.thc.org/root/phun/unmaintain.html, immagino. Avete mai provato a gestire o a prendere in mano un progetto scritto da qualcuno in modo procedurale? Been there, done that. Aggiungo, il problema non e' il modo procedurale. Il problema e' il progetto scritto ad minchiam. Mi è capitato un if con ben 6 (sei) altri if nidificati con un paio di while all' interno di ognuno su un singolo file (senza classi eh!) di ben 1230 righe, scritto da un professionista con stipendio da 2500€/mese che evidentemente si è fermato al 1998. Ma voglio dire, Django è bello, ma è giusto dire che è un framework e se parliamo di web, andrebbe paragonato almeno a Codeigniter, con il quale non si fanno solo i guestbook! Guarda che non e' questione di confrontare. Il modello di PHP 'vanilla' e' surrealmente demenziale (nel 2013). Non e' che un linguaggio senza librerie debba supportare la programmazione sul web, che e', soprattutto questione di ambiente. Avere martellato un linguaggio attorno a mod_php (o viceversa) non e' sintomo di furbizia. Per cui mi va benissimo che se voglio fare web (o gui o whatever) mi importo le librerie adatte. Detto questo, purtroppo, ci sono più offerte di lavoro con il PHP anche se il 99% di queste sono poco serie. Scusa, ma a me il valore assoluto delle offerte non mi interessa. E non interessa a nessuno che ci ragioni. Quello che interessa, e' il numero di offerte buone che uno trova. Buone vuole dire commisurate alle sue skill, retribuite il giusto, possibilmente con un ambiente di lavoro sensato (aggiungerei, con buone probabilita' di essere pagati). Sono più un cerco il programmatore PHP per sentito dire dal mio amico esperto che è capace di fare una pagina web con hello world. Poi con il passare del tempo ci si evolve... più che il PHP mi fa rabbia chi si fossilizza su quello che ha imparato 15 anni fa. Ovvero su chi persiste ad usare PHP? -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] E' piu' forte di me
2013/12/23 Balan Victor balan.vict...@gmail.com Li si vedono sui forum, un giorno affrontano roba web, qualche tempo dopo PyGame, poi Kivvy. Una manciata di anni dopo stanno macinando tool di meta-programmazione e deploy parecchio interessanti. Fra 10 anni, ci manderanno tutti a casa. Proprio a 14 anni e' bene partire con uno strumento che cresce con te. A volte per apprezzare uno strumento è utile conoscere i difetti degli altri. Ma non e' che partire a remare con il remo fatto a colino sia particolarmente didattico, eh... -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] E' piu' forte di me
2013/12/23 Balan Victor balan.vict...@gmail.com Il giorno 23 dicembre 2013 19:51, Carlos Catucci carlos.catu...@gmail.com ha scritto: Non e' piu' facile partire da, e' solo che credono sia piu' facile come il niubbo crede ia piu' facile windows di linux. Se provassero a pensare invece che credere magari andrebbe diversamente. Prova a spiegare a un ragazzino il modello MVC e vedi se riesci a tirare fuori qualcosa. Si, fatto. Dipende dal ragazzino. Dipende da chi spiega. Prova a spiegare a un ragazzino la programmazione procedurale e 2 giorni dopo ti trovi con un guestbook della madonna; sarà scritto in una maniera incomprensibile e non rispetterà nessuna regola del buonsenso, però intanto ha fatto un passo avanti e sicuramente non ha perso l'ENTUSIASMO. E allo stesso modo potresti avere fatto qualcosa con Django o con Flash che funziona. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] sfilza annuale di OOTO...
2013/12/24 Gollum1 gollum1.smeag...@gmail.com Il 23 dicembre 2013 10:53, Andrea Ambu andrea...@gmail.com ha scritto: Hanno un header Auto-Submitted: auto-.* con valore tipo auto-generated o auto-replied. http://www.iana.org/assignments/auto-submitted-keywords/auto-submitted-keywords.xhtml http://tools.ietf.org/html/rfc5436#section-2.7.1 domanda: con un filtro del tipo: Auto-Submitted: auto-.*, rischio di filtrare anche le risposte automatiche dei sistemi di registrazione online o i risponditori di quando faccio un submit di un qualche messaggio attraverso una pagina web, o sbaglio? da studiare bene... e poi potrebbe diventare molto utile, grazie delle info. Infatti io credo che debba essere fatto in entrata dalla mailing list: mailman potrebbe cestinare in modo safe la roba auto-submitted. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Concorrenza differita (era: Re: Deploy con nginx e proxy_pass)
On Tue, Dec 24, 2013 at 1:02 PM, Nicola Larosa n...@teknico.net wrote: Interessante, qui ci va una bella discussione sulla concorrenza. Solo che diversamente da voi che gozzovigliate, Si... oggi stavo lavorando, altro che no. io sto ficcando casa dentro tanti scatoloni per il trasloco, quindi per me se ne riparla dopo l'epifania. Sento il tuo dolore... ho tutt'ora la casa in tanti scatoloni. La memoria e' fresca... -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] sfilza annuale di OOTO...
Il 24 dicembre 2013 18:35, enrico franchi enrico.fran...@gmail.com ha scritto: Infatti io credo che debba essere fatto in entrata dalla mailing list: mailman potrebbe cestinare in modo safe la roba auto-submitted. anche perché non riesco (stranamente!?!?!) a filtrarlo con i filtri (di merd...) di gmail... non ho mai visto un sistema di filtraggio più schifoso, persino guarda fuori ha un sistema di filtraggio più decente... (come mi manca un sistema di filtraggio tipo procmail da remoto)... Byez -- Gollum1 Tesoro, dov'é il mio teoro... ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Concorrenza differita (era: Re: Deploy con nginx e proxy_pass)
2013/12/24 Roberto De Ioris robe...@unbit.it
Roberto De Ioris wrote:
odio la programmazione callback based
Interessante, qui ci va una bella discussione sulla concorrenza.
Solo che diversamente da voi che gozzovigliate, io sto ficcando casa
dentro tanti scatoloni per il trasloco, quindi per me se ne riparla dopo
l'epifania.
Ok,
#callback based:
def pluto():
print(fine);
def topolino():
wait_for('pluto', pluto)
def pippo():
wait_for('topolino', topolino)
wait_for('pippo', pippo)
# coroutine/greenthread/stackswitch/blah blah based:
wait_for('pippo')
pippo()
wait_for('topolino')
topolino()
wait_for('pluto')
pluto()
Personalmente trovo molto piu' leggibile la seconda forma (anche se
internamente l'implementazione e' piu' complessa) Se sei un fan di Go mi
darai regione (visto che e' come funzionano le goroutine) ;)
Mi sembra un chiaro caso in cui l'esempio stesso e' concepito a favore
della seconda forma.
Tutto molto lineare e sequenziale, nessuna gestione degli eventi.
Oh, poi io sono strano... io trovo il codice in cps piuttosto leggibile (e
lo capisco molto
meglio di codice che usi call/cc e analoghi, per intenderci). Di
conseguenza, non soffro
troppo con le callback.
E no, Node.js mi fa cacare. Oggi preferisco, in genere gevent a Twisted,
si.
E odio comunque fare monkey patching della stl...
--
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] TIOBE vs PYPL
2013/12/24 Enrico Bianchi enrico.bian...@ymail.com Leggendo questa affermazione, mi si rafforza la domanda sul perche` dovrei usare Go invece di Pascal... Perche' Pascal non ha le goroutine... perche' Pascal non ha il supporto che ha Go. Perche' trovo piu' librerie per Go che per Pascal (almeno per fare roba moderna)... Perche', alla fine dei conti, Pascal e' dire tutto e nulla... dovrei usare ObjectivePascal per avere qualcosa di sano. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] OT
Buone feste a tutti i pythonisti. Marcello ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Python bells..
Old school Christmas tune.. in pure python: http://bpaste.net/show/161512/ 1. Copiare / incollare da qualche parte 2. Lanciare lo script 3. Fare il play di python_bells.wav con il player preferito Auguri :-) Lorenzo. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python bells..
2013/12/24 Lorenzo Sutton lorenzofsut...@gmail.com Auguri :-) Lorenzo. Tanti auguri anche a te. Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python bells..
Auguri! .m .Massimo .Capanni σπευδε βραδεως Il giorno 24 dicembre 2013 20:41, Daniele Palmese pal...@gmail.com ha scritto: 2013/12/24 Lorenzo Sutton lorenzofsut...@gmail.com Auguri :-) Lorenzo. Tanti auguri anche a te. Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] TIOBE vs PYPL
On 12/24/2013 06:54 PM, enrico franchi wrote: Premetto: quando parlo di Pascal intendo FreePascal e, ovviamente, Lazarus (quindi si, ObjectPascal e` decisamente supportato) Perche' Pascal non ha le goroutine... Da quello che vedo, le goroutine permettono una programmazione parallela abbastanza semplice rispetto ad altri modelli. Posto che Pascal ha il supporto a OpenMP e OpenCL, puoi sempre derivare una classe da TThread e avviare il thread con la procedura start. Tra l'altro, ad occhio, il modello di parallelizzazione con le goroutines di Go e` di tipo threading, o sbaglio? perche' Pascal non ha il supporto che ha Go. Che intendi per supporto? Da quello che so (non ho visto, ammetto l'ignoranza), per Go c'e` il supporto di Google e basta, mentre per Pascal/Delphi hai un supporto decisamente vasto, soprattutto in virtu` dell'anzianita` del linguaggio. Se vogliamo sindacare a tal proposito, si, l'unico supporto multipiattaforma e` quello che trovi con FreePascal, in quanto Embarcadero Co. sono orientati solo sull'ambito Windows, ma anche qui le cose si stanno muovendo (poco, pero`) Perche' trovo piu' librerie per Go che per Pascal (almeno per fare roba moderna)... Definisci roba moderna, per favore. Dire faccio roba moderna e` come dire so cucinare. Per il discorso librerie, l'unica cosa che so e` che Go ha un repository centrale, mentre per FreePascal/Lazarus devi cercare in giro (anche se c'e` da dire che, a parte qualche libreria particolare, le librerie per Delphi sono compatibili e distribuite per Lazarus) Perche', alla fine dei conti, Pascal e' dire tutto e nulla... dovrei usare ObjectivePascal per avere qualcosa di sano. Ni, come in Python hai sia la programmazione procedurale che quella ad oggetti, e nulla di impedisce di usare una sola delle due (o tutte e due assieme) Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] TIOBE vs PYPL
Premesso che mi sfugge tutto questo interesse per Pascal... se proprio volessi scrivere qualcosa con un linguaggio di basso livello (leggi: compilato nativamente e senza GC) ma che al contrario di C non abbia così tanti undefined behavior, probabilmente mi affiderei ad Ada la cui ultima versione dello standard risale proprio all'anno scorso d'altro canto c'è anche TorChat, il cui autore stava cercando di riscriverlo da Python in Pascal, uno dei motivi principali sarebbe farlo girare su mobile (ma questo comunque non escluderebbe tutta la pletora di linguaggi managed che si possono usare) 2013/12/24 Enrico Bianchi enrico.bian...@ymail.com: Da quello che vedo, le goroutine permettono una programmazione parallela abbastanza semplice rispetto ad altri modelli. Posto che Pascal ha il supporto a OpenMP e OpenCL, puoi sempre derivare una classe da TThread e avviare il thread con la procedura start. Tra l'altro, ad occhio, il modello di parallelizzazione con le goroutines di Go e` di tipo threading, o sbaglio? Some people, when confronted with a problem, think, I know, I'll use threads, and then two they hav erpoblesms. non sono la persona più autorevole a riguardo, e per quanto abbia sentito certe tesi diverse volte, non sono sicuro di dove venga spiegata meglio, ma cercando su google, direi che questo paper mostra chiaramente i problemi nell'esporre i thread come strumento principale per sfruttare il parallelismo: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf ci sono diverse alternative: message passing (Erlang, Akka actors, Clojure agents, Go channels etc.), reducers ( http://vimeo.com/6624203 ), STM... in particolare, in Go... usare goroutine e limitarsi a comunicare dati fra di loro con i canali dovrebbe essere l'approccio più idiomatico, che difatti permette di evitare problemi tipici del gestire manualmente i thread -- xmpp: berda...@gmail.com bitmessage: BM-2cTYXfGiSTsnx3righ6aHcJSWe4MV17jDP gpg fingerprint: 3F8D53518012716C4EEF7DF67B498306B3BF75A0 (used just for signing commits) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
