[Python] saluti e prima domanda sulle list comprhension

[Enrico Franchi]

On Jan 28, 2008, at 11:32 AM, quilospam a email.it 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.