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
On Jan 28, 2008, at 8:47 PM, Java wrote: > Ma scusa, invece se lancio due processi, ognuno dei quali deve > scrivere > sullo stesso file non ci sono race conditions? In linea abbastanza teorica, si. In pratica il punto è *cosa* devono farci di sensato per scrivere tutti e due sullo stesso file. E' un log? Beh, allora basta lasciare gestire la cosa al sistema operativo: siamo solo in append e non importa se una delle due righe è prima dell'altra (e il buffering dell'OS Normalmente gestisce la cosa -- e se non lo fa, chissene). Hai più processi che devono scrivere sullo stesso file e non ci puoi fare nulla architetturalmente? Bene: è il momento per usare i lock. Esatto! Oppure, se per vari motivi la cosa è sensata/fattibile deleghi la scrittura ad un unico processo che prende messaggi dagli altri. Questa è la soluzione dello spooler di stampa, in buona sostanza. Ma in generale è quello che accade per esempio su un database system. Ci sono varie soluzioni, ovviamente. Ma la tua obiezione è del tipo: c'è un caso complicato e noioso che in determinate occasioni si manifesta. Per cui chi se ne impippa se lo facciamo manifestare sempre. Io invece ti rispondo: facciamolo manifestare il meno possibile. Dopo di che un conto è avere un lock su un'operazione di I/O che bloccherebbe comunque, un conto è avere un lock su una variabile in ram che di per se potrebbe essere gestita in qualche boh, qualche nanosecondo. Direi che sono cose *radicalmente* diverse. A fronte di *nessun* vantaggio concreto. > Devo comunque mettere su dei lock sul file e il processo che trova il > file lockato (ARGH!) si siede e aspetta giocando con la psp. E quindi? E' comunque I/O. Se non puoi evitare il problema, almeno rendilo raro. Inoltre, come dicevo, l'overhead su un'operazione di questo tipo è percentualmente molto più piccolo che averlo su un accesso in memoria. > qualcuno mi ha proposto la gestione asincrona della cosa, ma come ho > detto "asincrono" mi puzza di "gestione di eventi e segnali" che è di > certo più tediosa di un piccolo lock... 'Di certo' poi un accidenti. In primo luogo perchè buona parte del meccanismo ti viene gestito dal sistema (non è che twisted se lo sono inventato per il divertimento di fare passare una poll per 12 strati software diversi, eh). Anche fare le cose a mano, non è poi terribilmente noioso, se hai ben progettato il sistema. Ribadisco poi che con Twisted è tutto *gratis*. Nota bene che qui non sono mica solo io a dirti di tenerti lontano dai thread, ma c'è una certa unanimità a riguardo. Non è che ci siamo messi d'accordo. Come dicevo, potrei anche segnalarti fonti letterarie a riguardo. I thread sono spinti e difesi in sostanza dai javisti principalmente perchè se no gli crolla il mondo addosso. Hanno pure tentato approcci asincroni, ma non so se per incapacità loro, problemi di linguaggio, macchina virtuale o cosa, sono solo riusciti a complicare il tutto. Ma questo è un problema *loro*. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] saluti e prima domanda sulle list comprhension
> 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. > > lol, il copia&incolla è alla base di tutto > >> 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. Ma scusa, invece se lancio due processi, ognuno dei quali deve scrivere sullo stesso file non ci sono race conditions? Devo comunque mettere su dei lock sul file e il processo che trova il file lockato (ARGH!) si siede e aspetta giocando con la psp. qualcuno mi ha proposto la gestione asincrona della cosa, ma come ho detto "asincrono" mi puzza di "gestione di eventi e segnali" che è di certo più tediosa di un piccolo lock... p.s. mi sa che quando avremmo finito questa conversazione io avrò già dato l'esame :-p ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] saluti e prima domanda sulle list comprhension
Enrico Franchi ha scritto: > On Jan 28, 2008, at 11:32 AM, [EMAIL PROTECTED] wrote: > > > 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. Mi inserisco un attimo, perché sto impazzendo proprio in questi giorni con i thread sotto python e stavo per buttare tutto seguendo le vostre parole, quando questa frase mi ha fatto ripensare. 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? Vi scrivo un attimo quello che mi sta facendo impazzire: ho un programmino che ogni tanto deve essere capace di eseguire un'azione dopo un certo numero di secondi. Non mi interessa che il momento in cui la esegue sia precisissimo (per intenderci, se sbaglia anche di qualche secondo non me ne frega niente), ma: 1) il resto del programma intanto deve lavorare 2) non voglio complicarmi la vita 3) non voglio sprecare CPU inutilmente 4) l'azione da eseguire dipende dal thread principale Per il motivo 1), non posso fare un semplice sleep(numerodisecondi), per i motivi 2) e 3) non voglio fare un megaciclo, per il motivo 4) non voglio un processo separato. Perciò ho un thread che parte, si mette in sleep(numerodisecondi) e quando si "sveglia" esegue l'azione. Sbaglio? C'è un modo furbo per rispondere alle mie 4 esigenze senza usare thread? Fin qui la domanda teorica. A questo punto aggiunto che il mio programma usa le pygtk, ed entrambi i thread le utilizzano. So che gtk non è thread-safe, ma so anche che ci sono delle apposite funzioni che rendono i thread "compatibili" nel momento in cui utilizzano oggetti gtk. 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? grazie Pietro ___ 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. > 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
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
> 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... 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. 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 :-) 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) -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: KILL BILL! scarica la colonna sonora del film: è in REGALO! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6614&d=20080128 ___ 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
Re: [Python] saluti e prima domanda sulle list comprhension
> >> lancia un altro processo invece di far partire un thread, che problema >> c'è? >> se proprio vuoi puoi imparare twisted[1] ;) >> >> > Ma perché avete tutto questo astio per i poveri thread? Perchè è una soluzione sbagliata a un problema complesso. Il multiprocesso funziona meglio, è più gestibile e pone meno problemi, inoltre 9 su 10 sulle macchine moderne scala meglio. Il monoprocesso con gestione asincrona degli eventi è ancora meglio, più performante e senza nessun problema di condivisione dei dati. Gestire lo stato condiviso tra thread è un masochismo esagerato sul serio! > almeno così mi ricordo dalla teoria dei thread in generale, tipicamente > un processo è una cosa più pesante > Su processori multicore (moltissimi oggi, praticamente tutti domani, almeno nel segmento consumer e server) il multiprocesso è più performante del multithreading praticamente sempre. Per non parlare del fatto che il multiprocesso scala meglio anche con un singolo core, se c'è stato condiviso... > > MMM poi quella cosa di twisted mi tenta un casino... mmm mmm vedo se ci > sto dentro come tempi > Faresti un'ottima cosa, sia a livello didattico che pratico! -- 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
> lancia un altro processo invece di far partire un thread, che problema c'è? > se proprio vuoi puoi imparare twisted[1] ;) > > Ma perché avete tutto questo astio per i poveri thread? Se manca la rete: 1) è un crawler, se manca la rete può anche andare a farsi friggere 2) scatta il timeout che catturo con un eccezione 3) non può bloccarsi tutto, proprio perché è un thread, al massimo si blocca lui e il resto va... almeno così mi ricordo dalla teoria dei thread in generale, tipicamente un processo è una cosa più pesante MMM poi quella cosa di twisted mi tenta un casino... mmm mmm vedo se ci sto dentro come tempi > juno ja jcaso jdisimparalo jall'jistante ;) > > ARGH! Java non deriva dal linguaggio di programmazioe! Ma è il nome di un personaggio che mi ero creato epr giocare ad un MUD (Dalila) anni fa e l'avevo scelto per via del tipo di neanderthal amico di martyn mystere! ___ 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 6:22 PM, Java wrote: > No, il proff vuol poter lanciare più processi crawler in parallelo e > poi > vuole che si analizzino i risultati finali. 1. fare le cose in parallelo non implica farle con i thread 2. oltre al modello a processi, c'è pure il modello asincrono. Il quale probabilmente è quello che garantirebbe la migliore efficienza, per inciso. BTW: delle tre cose, la peggiore è quella di usare i thread. > 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 Risconsiglio i thread. > L'input arriva da "fuori" è un parametro del costruttore del thread, e > anche i vari print mi servono solo per debug, poi li levo tutti e > metto > il try-except Quindi mi pare un errore logico comunque. Prendi 'da fuori' una stringa che rappresenta un'intero e la converti 'ad un certo punto'. La cosa corretta è passare al costruttore il valore giusto. O eventualmente fare smazzare la cosa al costruttore. O se ti piace menartela con i design pattern, vai con l'Adapter (ecco, tipo a me pare una di quelle cose roboanti introdurre una classe apposta per una cosa del genere, specie in Python, ma almeno ci sono le zope.interfaces, va). > me ne ero accorto :-( > Chissà perché ero convinto che così facendo avrei copiato i valori dda > una lista all'altra invece di farle puntare tutte allo stesso oggetto. > In effetti non è un errore di python, ma di programmazione in > generale (>_>) Au contraire! È un errore di Python (ma anche di Java, volendo). In C+ + per esempio in caso di assegnamento c'è tipicamente la copia (a meno che non siano definite cose strane -- e con comunque il 'problema' è una shallow copy). In Python l'assegnamento tipicamente non duplica un valore. Le variabili sono sempre e solo riferimenti ad oggetti. Per copiare un oggetto, usi un metodo che ne crei uno nuovo e ritorni quello. Ovviamente la cosa è rilevante solo con gli oggetti mutabili. Le stringhe sono immutabili: concatenare stringhe con il + è inefficiente precisamente per questa ragione (ogni somma crea una nuova stringa, n somme, creano n stringhe). > il for è la prima cosa a cui penso (dopo anni di c, c++, java etc etc) > ma mi "forzo" ad usare le list comprecose per impararle bene In primo luogo il for di Python è *diverso* da quello di C++. Ma a parte questo usare le list comprehensions a sproposito non è un buon modo per impararle. Posto che quello che hai scritto è sintatticamente corretto, chiunque leggesse quel codice si chiederebbe se sei consapevole che extend modifica in place e che cosa vuoi fare con una lista di None. L'idea della list comprehension è questa: costruisci una lista di f(x) con gli x provenienti da un iterabile (se vale una certa condizione su x). In pratica nella list comprehension il return value è pragmaticamente importante. > N i "fondamentali" sono tutti i linguaggi che già conosco :-p Mah. Ribadisco, un'occhiatina alla semantica di Python la darei, tanto per evitare altre cattive sorprese. ___ 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
> 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. > > > No, il proff vuol poter lanciare più processi crawler in parallelo e poi vuole che si analizzino i risultati finali. 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 > brrr... ma così, dentro un thread prendi input da un utente? > Se l'input lo prendi fuori, falla *fuori* la conversione, > L'input arriva da "fuori" è un parametro del costruttore del thread, e anche i vari print mi servono solo per debug, poi li levo tutti e metto il try-except > eventualmente con un gestore di eccezioni. > per l'appunto ;-D > Ehm. Guarda che fai: temp = results. Per cui entrambi puntano allo > stesso oggetto. > me ne ero accorto :-( Chissà perché ero convinto che così facendo avrei copiato i valori dda una lista all'altra invece di farle puntare tutte allo stesso oggetto. In effetti non è un errore di python, ma di programmazione in generale (>_>) > 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)) > > il for è la prima cosa a cui penso (dopo anni di c, c++, java etc etc) ma mi "forzo" ad usare le list comprecose per impararle bene > Ti suggerisco di studiarti bene i fondamentali. > > N i "fondamentali" sono tutti i linguaggi che già conosco :-p ___ 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. :) > 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
> temp e results fanno riferimento allo stesso oggetto, e quindi quello > che stai in realtà facendo è qualcosa tipo: > > l = [1] > [l.append(i) for i in l] > > Si, c'ero appena appena arrivato da me facendo delle prove con la consolle python... infatti sostituendo con: temp.extend(results) fa funzionare il tutto! grazie per la risposta, ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] saluti e prima domanda sulle list comprhension
Java ha scritto: > Salve a tutti, sono nuovo di questa mailing list e del pythone più in > generale! > > 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 > > 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... > > 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. Cioè se questa è 1 "parso" (ARGH!) solo la pagina iniziale, se > vale 2 parso anche tutti i link in essa e così via... > > ecco il codice: > > 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) ># 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! > In pratica continua a ciclare come se ogni volta eseguisse temp = > results, ma non capisco il perché... > > qualche idea? > temp e results fanno riferimento allo stesso oggetto, e quindi quello che stai in realtà facendo è qualcosa tipo: l = [1] [l.append(i) for i in l] Nella list comphrension la lista è valutata in modo lazy, quindi hai un ciclo infinito. Manlio Perillo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] saluti e prima domanda sulle list comprhension
Salve a tutti, sono nuovo di questa mailing list e del pythone più in generale! 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 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... 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. Cioè se questa è 1 "parso" (ARGH!) solo la pagina iniziale, se vale 2 parso anche tutti i link in essa e così via... ecco il codice: 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) # 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! In pratica continua a ciclare come se ogni volta eseguisse temp = results, ma non capisco il perché... qualche idea? --Segolas ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
