Re: [Python] saluti e prima domanda sulle list comprhension
On Jan 28, 2008, at 8:43 PM, Pietro Battiston wrote: In sostanza: concesso che utilizzare tanti thread che fanno le stesse cose sia sbagliato per motivi di comodità e/o di efficienza, ammettete casi in cui invece sia bene utilizzare i thread per fare cose diverse? In generale no. I thread (a memoria condivisa) sono praticamente *sempre* una complicazione a livello applicativo. Personalmente ammetto i thread come sensati solo per staccare un lavoratore che deve fare un calcolo pesante senza fermare l'UI di un programma. In questo caso sarebbe comunque possibile un processo nella maggior parte dei casi, tuttavia il thread può essere più comodo in presenza di strutture sostanzialmente asincrone *intraprocesso*. Ovvero a quel punto il thread, appena prima di terminare, notifica la cosa e il risultato a qualcuno che poi si prende la briga di passare l'informazione a chi di dovere (sempre in modo asincrono). In particolare per questa architettura ho in mente specialmente Cocoa. In altri casi potrebbe essere *comunque* fare fare la cosa ad un processo e usare altri meccanismi di comunicazione. Ma nota che a questo punto la faccenda è puramente tecnologica: il thread si sta comportando esattamente come un processo (perchè lo rendo completamente cieco a quello che non deve vedere e non gli permetto di toccare alcunchè). E' un thread poichè nella specifica piattaforma viene più comodo a livello implementativo, ma a livello logico/architetturale la struttura è la stessa che se avessi un processo. Il fatto di usare gtk mi dà un modo (semplice) alternativo di dare un'azione da eseguire dopo un tot di tempo, senza nel frattempo paralizzare la GUI? Io non conosco GTK, ma nei vari toolkit grafici che ho incontrato ci sono dei timer che fanno in modo automatico quello che tu vuoi, senza bisogno di tirarsi fra le palle un thread solo per quello. Se poi l'azione è *intrinsecamente lenta a livello utente* (ovvero si misura in termini di *secondi*, che come tempo macchina sono una mezza eternità), puoi considerare architetture. Io facendo una banale ricerca su google ho trovato: http://personal.riverusers.com/~swilhelm/gtkperl-tutorial/timersandio.html (in Perl, ma dovrebbe essere sostanzialmente adattabile) E questa è quasi tutta roba asincrona, eh. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] saluti e prima domanda sulle list comprhension
Il giorno 28/gen/08, alle ore 11:32, [EMAIL PROTECTED] ha scritto: Al di la di quello che rende 'semplice' un popolare linguaggio di programmazioni progettato da qualche control freak, il problema è che il modo più naturale, logico e comodo di lavorare con i thread è un modello a messaggi/code e *senza* stato condiviso. Bho, fore ora andiamo anche OT, ma mi sento di dissentire quest'ultima affermazione. Se non altro dopo tutti i vari filosofi a cena e barbieri fatti a laboratorio concorrente. I Thread lavorano su strutture dati condivise. E in generale il dato condiviso fa parte dello stato del programma... Strutture dati condivise che devono essere adeguatamente protette dall'accesso concorrente, se non vuoi i bug più bastardi che esistano. Tra l'altro, bug, deadlock e quant'altro, imprevedibili e che spesso *non* si presentano sul sistema di testing, ma solo quando il software va a regime, in produzione. Il multithreading a stato condiviso è troppo difficile da gestire, non ne vale sul serio la pena, soprattutto dal momento che il multiprocesso non è idealmente così distante, IMHO...diverso è se consideri l'approccio asincrono, lì va riconsiderata tutta l'architettura, e magari non è quello che ti serve per l'esame, ma io considererei bene di adottare un'architettura multiprocesso piuttosto che multithread a stato condiviso! -- Antonio Valente ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] saluti e prima domanda sulle list comprhension
On Jan 28, 2008, at 11:32 AM, [EMAIL PROTECTED] wrote: Bho, fore ora andiamo anche OT, ma mi sento di dissentire quest'ultima affermazione. Dissenti, ma sbagli :) Se non altro dopo tutti i vari filosofi a cena e barbieri fatti a laboratorio concorrente. Quindi? In primo luogo, cerchiamo di capire quale è il senso. Sono problemi *teorici*, spesso usati come metro per valutare una nuova primitiva di sincronizzazione. Ancora una volta, in se e per se, è un discorso accademico/teorico. Ci sono contesti in cui bisogna gestire i thread (esempio in un kernel, o in particolari applicazioni semi-embdedded). Su un'applicazione di alto livello, la cosa non funziona, non scala. Non ci sono santi. MySQL ha dimostrato chiaramente come il modello a thread scali male sull'I/O. Ma ci sono un mucchio di esempi. Lo stato condiviso è creare un problema e poi mostrare come si può risolverlo. Il che mi diverte anche quando affronto le cose da un punto di vista teorico *e* mi interessa pure se non ho altra strada. Ma quando posso evitare, lo faccio e basta: tipicamente non ho tempo da perdere. Potrei anche citarti le parole di Van Roy e Haridi. Ormai le ho copia- incollate tante di quelle volte che quasi le so a memoria. g I Thread lavorano su strutture dati condivise. E in generale il dato condiviso fa parte dello stato del programma... Solo ed esclusivamente se uno vuole cattive performance e divertirsi a debuggare race conditions e altri heisenbugs. In particolare il modo più naturale per lavorare fra thread è precisamente quello del passaggio di messaggi. Nota che è qualcosa che ci viene insegnato anche dalla comune esperienza: se devi mettere due persone a lavorare su qualcosa, è bene dividere le responsabilità e fare comunicare, *non* lasciare che mettano le mani nelle stesse cose. Tra l'altro un computer è notevolmente più stupido di un essere umano, per cui non ha il buon senso di non fare certe cose: il tutto resta a carico del programmatore. Programmatore che avrebbe anche di meglio da fare, diciamocelo. Ma secondo me è più un problema di stile, senz'altre conseguenze pratiche. A me pare più pulito usare i thread, certo sarebbe meglio creare un pool di thread da riciclare... e forse lo farò, ma di sicuro non è l'obiettivo principale dell'esame. E sbagli: il punto chiave è che proprio il meccanismo a thread non è particolarmente adatto. Non solo, in un mondo in cui si va verso il grid-computing, è pure anacronistico. Hai due modi efficienti di gestire la cosa: 1. usare la programmazione asincrona (ma gestirla a basso livello è una rogna, specie se devi ben intervallare compiti di calcolo e compiti di I/O. 2. usare un modello a processi. In questo caso è tutto *assolutamente* banale. Hai un processo 'padre' che coordina il tutto e dei processi figli che chiedono informazioni su cosa eseguire. Lanciare processi in unix (e anche farlo con python) è qualcosa di oltremodo poco costoso. Ma tu tra l'altro non vuoi veramente lanciare una caterva di processi. Diciamo 5 processi (contando il padre). O 9. O un numero che piace a te. Il padre (possibilmente in maniera asincrona -- ma a questo punto è abbastanza facile anche senza oggetti di alto livello) ascolta i figli. Questi danno informazioni e prendono ordini. Il padre ha l'informazione 'totale' e quando si ha finito risponde. Per la cosa del proff, dovrebbe essere abbastanza tranquillo, di solito se (raramente!) non capiscono qualcosa non pensano che sia sbagliato, ma anzi si complimentano di aver usato cose nuove e di avergliele fatte scoprire :-) Sarai fortunato, vah. Comunque, per quanto sia un confronto che mi stimola, forse è meglio non farlo su questa ml ( mano che gli admin non siano un po' elastici :-D) Gli 'admin' non saprei neppure dire chi sono, in effetti. Cioè quelli 'fisici' direi di si, quelli 'spirituali' non so più come si situa la ML rispetto a python.it e di conseguenza rispetto a Python Foundation. Ad ogni modo ti garantisco io di persona personalmente che non ci sono problemi e si può proseguire. Anche non volendo *siamo* IT. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] saluti e prima domanda sulle list comprhension
On Jan 27, 2008, at 5:34 PM, Java wrote: Salve a tutti, sono nuovo di questa mailing list e del pythone più in generale! Io suggerirei di cambiare nome. g :) Prima di fare la domanda, preannuncio che mi sono occupato di questa cosa per un paio di giorni, e che essendo completamente niubbo con il python potrei aver fatto qualche cavolata :-D Il che è naturale e altrimenti non posteresti qui. Aggiungo inoltre... la prima cavolata che i principianti fanno è applicare in toto strutture mentali che provengono da altri linguaggi. Veniamo alla nota dolente, devo fare un progetto per l'università(costruire una rete sociale di video di youtube) che comporta anche la scrittura di un piccolo crawler. Ho pensato di usare python sostanzialmente perché non lo conoscevo, e così approfitto dell'esame per imparare un nuovo linguaggio... Interessante e ottimo proposito. Senza entrare troppo nei dettagli, ho fatto un thread che si occupa di fare il crawling di una pagina iterando per in base alla profondità di crawling. Male: perché usare un thread? Ogni programmatore che si rende conto che spesso e volentieri i thread sono la risposta sbagliata ad un non problema è una speranza per un futuro migliore. Diciamocela tutta: se in Java si programma con i thread (a memoria condivisa), questo non vuole dire che debba essere buona pratica ovunque. Io in particolare per quello che fai tu userei multiprocesso. No: mento sapendo di mentire, forse userei un'altra cosa, ma non voglio complicarti ora la vita. def run ( self ): # lista temporanea temp = [] # all'inizio la lista results contine l'url iniziale results = [self.start_url] #cast della profondita' in intero poiché la leggo da input p = int(self.profondita) brrr... ma così, dentro un thread prendi input da un utente? Se l'input lo prendi fuori, falla *fuori* la conversione, eventualmente con un gestore di eccezioni. # finche' la profondita' e' maggiore di zero, intero sulla lista temp eseguendo il # parsing degli url trovati in essa while(p 0): print Thread lanciato con profondita: , p # copio i risultati attuali dentro la lista temp # all'inizio conterrà solo un url temp = results print ecco la lista TEMP: print temp [results.extend(self.parseUrl(video)) for video in temp] print finito ciclo while \n\n\n # qua non ci arrivo mai :-( p-=1 il problema è che in ogni caso non esce mai dalla list comphrension, eppure la lista temp contiene un solo url! Ehm. Guarda che fai: temp = results. Per cui entrambi puntano allo stesso oggetto. A questo punto hai un ciclo che per ogni video che trova in temp, aggiunge una cosa a results. Ovvero a temp. Una nota stilistica: l'uso che fai della list comprehension è IMHO sbagliato. Una list comprehension (pur essendo completamente generale) tipicamente viene usata per generare un nuovo array. Ha insomma un significato in cui il valore di ritorno della funzione ha *profondo* significato (e spesso questo nuovo array viene manipolato in seguito). Tu invece la stai chiamando con un metodo che restituisce None. Il tuo codice anche se funzionasse, sarebbe 'bruttino'. Riscriviamolo con un for. for video in temp: results.extend(self.parseUrl(vide)) Ecco... ora dovrebbe essere chiaro l'inghippo. Guarda questo codice (viene dall'interprete interattivo ipython): In [58]: a = [x] In [59]: for el in a: : print a : a.append(el) : ['x'] ['x', 'x'] ['x', 'x', 'x'] ['x', 'x', 'x', 'x'] ['x', 'x', 'x', 'x', 'x'] ['x', 'x', 'x', 'x', 'x', 'x'] ['x', 'x', 'x', 'x', 'x', 'x', 'x'] Questo è evidentemente e ovviamente sbagliato. Ora rendiamolo più simile al tuo codice: In [62]: a = [x] In [63]: b = a In [65]: id(a) == id(b) Out[65]: True In [66]: print id(a), id(b) 7864368 7864368 In [67]: for el in a: : print a : b.append(el) : ['x'] ['x', 'x'] ['x', 'x', 'x'] ['x', 'x', 'x', 'x'] ['x', 'x', 'x', 'x', 'x'] Cioè tu iteri su qualcosa, ma aggiungi ad ogni iterazione un elemento. Ovvio che non termini. In pratica continua a ciclare come se ogni volta eseguisse temp = results, ma non capisco il perché... Ti suggerisco di studiarti bene i fondamentali. Ti saresti reso conto che dopo avere fatto temp = results, entrambi sono riferimenti allo stesso oggetto. Da cui modificando attraverso uno quell'oggetto, la modifica la vedi anche sull'altro. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] saluti e prima domanda sulle list comprhension
Java wrote: No, il proff vuol poter lanciare più processi crawler in parallelo e poi vuole che si analizzino i risultati finali. che sinceramente, per un problema che include l'uso della rete, usare i thread è la cosa più lenta che si possa fare :D Poi, scusa, messa così vale anche per i processi, che vengono eseguiti in 'parallelo', allo stesso modo dei thread, solo che elimini un casino di problematiche in più (se per caso una connessione si pianta cosa succede? rimane tutto in attesa che si liberi o no?) Rivedi un pochino le specifiche se per caso non stai assumendo un po troppo, che detta così come l'hai scritta è fattibilissimo usando i processi. Poi io ho pensato di realizzare la cosa con un programma principale che esegue un ciclo nel quale accetta dei comandi dall'utente. Se il comando è crawler allora aprte il thread. Poi conterrà anche i comandi per generare la rete sociale dai risultati del crawling (salvati su file) e per altre operazioni lancia un altro processo invece di far partire un thread, che problema c'è? se proprio vuoi puoi imparare twisted[1] ;) In effetti non è un errore di python, ma di programmazione in generale (_) mah, in c++ potrebbe aver anche avuto senso[2], indi *è* un errore di/in python il for è la prima cosa a cui penso (dopo anni di c, c++, java etc etc) tra l'altro, il for di python c'entra nulla con quello del c e dei suoi derivati :) ma mi forzo ad usare le list comprecose per impararle bene mah, sii il più chiaro possibile, explicit is better than implicit N i fondamentali sono tutti i linguaggi che già conosco :-p juno ja jcaso jdisimparalo jall'jistante ;) [1] ok, l'ho nominato io :D http://twistedmatrix.com [2] dipende tutto da cosa siano, se puntatori è un errore, se istanze anche no se esiste operator= -- ()_() | Bisogna stare attenti a generalizzare le cose che | + (o.o) | si apprendono con java. Altrimenti si finisce per | +---+ 'm m' | concludere che programmare e' un'attivia' noiosa, | O | (___) | cosa che non e' per nulla vera! :-) - Antonio Cuni | raffaele punto salmaso at gmail punto com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] saluti e prima domanda sulle list comprhension
On Jan 27, 2008, at 11:54 PM, Java wrote: Ma perché avete tutto questo astio per i poveri thread? Ho io non avevo astio con i thread. Finché non ho cominciato a ragionarci seriamente in ottica non banale. Al di la di quello che rende 'semplice' un popolare linguaggio di programmazioni progettato da qualche control freak, il problema è che il modo più naturale, logico e comodo di lavorare con i thread è un modello a messaggi/code e *senza* stato condiviso. A questo punto si che magari scala anche bene[0]. [0] su questo ci torniamo poi. 3) non può bloccarsi tutto, proprio perché è un thread, al massimo si blocca lui e il resto va... Si, ma non è li il problema, eh. almeno così mi ricordo dalla teoria dei thread in generale, tipicamente un processo è una cosa più pesante Tipicamente su un sistema progettato male. Su un sistema unix il costo è paragonabile. Inoltre se devi lanciare tanti processi/thread o ti chiami Erlang oppure ti conviene andare asincronamente. Sia con twisted, sia con il 'divertentissimo' poll. Nota poi che visto e considerato che fai principalmente I/O, senza dubbio prenderei un modello a processi. MMM poi quella cosa di twisted mi tenta un casino... mmm mmm vedo se ci sto dentro come tempi Sarebbe una gran cosa, ma IMHO non è il caso. Rischi solo di scrivere codice che il tuo docente non saprà capire. Io non lo conosco (il tuo docente), ma l'approccio di molti professori di fronte ad una cosa che uno studente fa e che loro non capiscono è 'è sbagliato/è fatto male'. Se il tuo professore non rientra in questa categoria, allora sicuramente Twisted è molto affascinante. Nota poi che per quello che devi fare tu, devi imparare un infinitesimo di tutto Twisted. Se poi passa e legge il Presidente, per convincerti, potrebbe pure buttare giù lo scheletro funzionante in 15 righe :P Ti confesso che sarei tentato di farlo io (non fosse che è un po' di tempo che non magheggio con Twisted e non vorrei scriverti un esempio 'vecchio'). Toh, a proposito di vecchie API. Twisted.web è abbastanza vecchio, a quanto mi dicono dalla regia, sarebbe da passare con twisted.web2 http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/525493 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
