Newsgroup: it.comp.programmare
Titolo: [Python](no subject)

In un post di un po' di tempo fa su free.it.python si parlava di
stackless python come un modo per controllare il flusso di un
programma, qualcuno potrebbe spiegarmi esattamente cosa si intende in
modo *molto* semplice
Marco Barisione


Nel normale interprete Python, lo stato dell'interprete viene salvato nel 
normale stack del C quando vi sono chiamate a funzioni o metodi: e` 
l'approccio piu` semplice da programmare in C, basta che le variabili che 
contengono questo stato siano "automatiche" (il default per le variabili 
locali del codice C) e il C le tiene appunto nello stack.  Questo approccio 
inoltre si presta bene al porting ad altri linguaggi, come Java (infatti il 
codice Java dell'interprete Jython e` molto simile al codice C del Classic 
Python per quel che riguarda questo aspetto).
Non e`, pero`, l'approccio piu` efficiente, ne` il piu` flessibile.  
Stackless Python mantiene l'intero stato dell'interprete esplicitamente 
salvato in oggetti-frame, senza usare a questo scopo lo stack del C.  Le 
prestazioni sono migliori (circa il 5% in casi tipici) in quanto con questo 
approccio esplicito Stackless salva solo l'esatta quantita` di stato che e` 
indispensabile salvare, non un bit di piu`, e la salva e la recupera nel modo 
piu` diretto.  La flessibilita` e` maggiore in quanto, mentre uno stack e` 
rigorosamente LIFO, una collezione di oggetti-frame puo` essere agevolmente 
usata nello stesso modo (ad esempio facendone una semplice linked-list) ma 
anche in altri modi (passando da un frame ad un altro piu` liberamente, 
mantenendo attivi molteplici frame, ecc), cosi` da realizzare strutture di 
controllo estremamente ricche ("Call/CC" in termini Scheme, microthread, 
generatori con un approccio assai diverso da quello usato in Python 2.2, e 
cosi` via).  Stackless Python rende disponibile questa ricchezza anche a 
livello di Python attraverso il suo modulo "continuation".
Guido pare non intenda integrare Stackless nel Python mainstream in quanto la 
flessibilita` che permette non e` portabile alla JVM (e forse solo con 
difficolta` su .NET), e la complessita` del codice e` notevole.  I generatori 
infatti usano tutt'altro schema in Python 2.2 (generazione di un oggetto di 
tipo apposito, non riuso dell'oggetto-frame) e non vi e` l'intera generalita` 
delle continuation (niente microthread, ecc ecc), solo un sottoinsieme molto 
semplice (che certo corrisponde a una buona fetta degli usi).
Stackless Python si puo` dunque considerare un 'fork' di Python per usi 
specializzati: ha un piccolo ma accanito manipolo di seguaci, soprattutto per 
l'uso micro-thread (tipicamente cooperativi, NON pre-emptive, per efficienza).
Alex
 
_________________________________________________________
Do You Yahoo!?
Get your free @
yahoo.com
 address at 
http://mail.yahoo.com
 
 

 piu` diretto.  [...]
Ma con stackless python uno script python normale funziona
normalmente? Se sì perché non si utilizza normalmente questa versione,
giusto per il 5% in + di velocità?
Marco Barisione

 giusto per il 5% in + di velocità?
Nessuno te lo impedisce!  La maggior parte degli utenti preferisce usare la 
distribuzione standard (Stackless devi scaricarlo, credo, come patch rispetto 
ai sorgenti della versione base, farti il build, ecc; e naturalmente viene 
adattato alle novita` della versione base solo con un po' di ritardo ogni 
volta).  I vantaggi di prestazioni andranno misurati caso per caso; il "5%" 
e` solo un'indicazione media, le variazioni sono ampie.


 e` solo un'indicazione media, le variazioni sono ampie.
Già ma se stackless diventasse la distribuzione standard sarebbe
semplice da usare come la versione C (ad es. exe autoinstallante per
win) e potrebbe aumentare la velocità (anche se di poco) visto che una
comune lamentela riguardo a python è la velocità (anche se a dire il
vero riscontro i problemi di velocità di + in fattori esterni come ad
esempio la velocità dell'os a ridisegnare i controlli grafici).
Marco Barisione

esempio la velocità dell'os a ridisegnare i controlli grafici).
la compatibilita` afaik vale solo per i programmi scritti esclusi-
vamente in python, che alla fine temo non siano la maggioranza delle
applicazioni python di un certo peso
--
saluti
f.riccardo

f.riccardo [mailto:
pyth...@tiscalinet.it
] scrive:
	...

A parte i soliti problemi (su Windows devo ricompilare/rilinkare ogni
estensione C/C++ ad ogni release di Python), non vi sono incompatibilita`
fra le API C esibite da stackless python e quelle esibite da classic
python.  Non credo che stackless esibisca direttamente neppure delle
API supplementari.
Una differenza di velocita` del 5% e` irrilevante nella realta` pratica,
per quanto cruciale nel marketing, relativamente ai benchmark (se la
target audience e` sufficientemente ingenua da lasciarsi incantare dai
benchmark).  E` sicuramente vero che l'utente finale di Python (e anche
la grande maggioranza degli autori di estensioni C) non avrebbe alcuna
particolare difficolta` se Guido scegliesse (come pare non fara`) di
pacchettizzare Stackless invece dell'attuale versione classica.  
Tutti i problemi li avrebbero i manutentori di Python stesso, visto 
l'aumento di complessita` che questo ipotetico passaggio comporterebbe 
negli stessi sorgenti di Python: invece di sviluppare cosette come 
l'integrazione fra tipi e classi, l'uniformita` fra long e int, eccetera, 
Guido e soci si dovrebbero concentrare sulla stabilizzazione e tuning 
delle novita`, oltre che sul familiarizzarsi con esse, per un tot di 
tempo, almeno sino a che le novita` non risultino completamente digerite.  
Se il delta di complessita` e` sufficientemente alto, la produttivita` 
del gruppo che sviluppa gli internals di Python sarebbe permanentemente 
ridotta dopo questo passaggio.  Un elemento certo, e molto alto, di 
riduzione di produttivita`, sarebbe nella inevitabile divergenza fra 
i sorgenti di Python-per-C (divenuto ipoteticamente stackless) e quelli 
di Python per Java e Python per .NET.
Fra i punti di forza di Python c'e` sempre stata la cristallina, limpida
semplicita` della sua *implementazione*: invito chiunque conosca un
poco di C a studiarsi i sorgenti di Python stesso, e poi quelli di
Perl, per vedere cosa intendo.  Con poche peculiari eccezioni dovute
a ottimizzazioni molto spinte (il parser, alcuni aspetti degli oggetti
dizionario), i sorgenti di Python sarebbero proponibili come "case
study" per programmatori principianti dopo 6-8 mesi di corso di C.
Alex

 API supplementari.
toh, come gia` detto l'avevo letto da qualche parte, da
http://www.onlamp.com/pub/a/python/2000/10/04/stackless-intro.html
%Tismer continues to pour effort into Stackless to improve several
%details. Stackless is already entirely compatible with existing "pure"
%Python applications -- those developed exclusively in Python. Many
%Python applications, however, involve fragments coded in other
%languages, generally C. Python's willingness to "play nicely" with
other
%languages is one of its principal virtues for many programming teams.
mah non che parli espressamente di incompatibilita` ma quantomeno
fa sorgere il dubbio
--
saluti
f.riccardo
[sostituire 
linux.it
 al dominio nell'indirizzo]