Non so da dove provenga "Stackless è il 10% più veloce" del Wiki, ma di nuovo non ho mai provato a misurare quei numeri di prestazioni. Non riesco a pensare a cosa sia Stackless per fare la differenza così tanto.
Stackless è uno strumento straordinario con diversi problemi organizzativi/politici.
Il primo viene dalla storia. Christian Tismer iniziò a parlare di ciò che alla fine divenne Stackless circa 10 anni fa. Aveva un'idea di ciò che voleva, ma aveva difficoltà a spiegare cosa stava facendo e perché la gente dovrebbe usarlo. Ciò è in parte dovuto al fatto che il suo background non ha avuto la formazione di CS su idee come le coroutine e perché le sue presentazioni e discussioni sono molto orientate all'implementazione, il che è difficile per chiunque non sia ancora all'avanguardia nel capire come usarlo come soluzione per i loro problemi.
Per questo motivo, la documentazione iniziale era scadente. C'erano alcune descrizioni su come usarlo, con il meglio dei contributori di terze parti. Al PyCon 2007 ho tenuto un discorso su "Using Stackless" che è andato abbastanza bene, secondo i numeri dell'indagine PyCon. Richard Tew ha svolto un ottimo lavoro raccogliendo questi, aggiornando stackless.com e mantenendo la distribuzione quando si presentano nuove versioni di Python. È un impiegato di CCP Games, sviluppatori di EVE Online, che utilizza Stackless come parte essenziale del proprio sistema di gioco.
I giochi CCP sono anche il più grande esempio di utilizzo del mondo reale quando parlano di Stackless. Il tutorial principale per Stackless è "Introduction to Concurrent Programming with Stackless Python" di Grant Olson, anch'esso orientato al gioco. Penso che ciò dia alla gente un'idea distorta del fatto che Stackless è orientato ai giochi, quando è più che i giochi sono più facilmente orientati alla continuazione.
Un'altra difficoltà è stato il codice sorgente.Nella sua forma originale richiedeva modifiche a molte parti di Python, il che rendeva Guido van Rossum, il capo di Python, diffidente. Parte del motivo, penso, era il supporto per call/cc che è stato in seguito rimosso come "troppo simile a supportare un goto quando ci sono forme migliori di livello superiore". Non sono sicuro di questa storia, quindi leggi questo paragrafo come "Stackless usato per richiedere troppe modifiche".
Le versioni successive non hanno richiesto le modifiche e Tismer ha continuato a spingere per l'inclusione in Python. Mentre c'era qualche considerazione, la posizione ufficiale (per quanto ne so) è che CPython non è solo un'implementazione Python ma è intesa come un'implementazione di riferimento, e non includerà la funzionalità Stackless perché non può essere implementata da Jython o Iron Python.
Non ci sono piani per "modifiche significative al codice". Quella citazione e il collegamento ipertestuale di riferimento da Arafangion (si veda il commento) risalgono a circa 2000/2001. I cambiamenti strutturali sono stati a lungo fatti, ed è ciò che ho menzionato sopra. Lo stackless com'è ora è stabile e maturo, con solo piccole modifiche alla base del codice negli ultimi anni.
Un'ultima limitazione con Stackless: non esiste un forte difensore per Stackless. Tismer è ora profondamente coinvolto con PyPy, che è un'implementazione di Python per Python. Ha implementato la funzionalità Stackless in PyPy e lo considera molto superiore allo stesso Stackless e ritiene che PyPy sia la via del futuro. Tew mantiene lo Stackless ma non è interessato alla difesa. Ho considerato di essere in quel ruolo, ma non vedevo come potevo ricavarne un reddito.
Anche se si desidera un allenamento in Stackless, sentirsi libero di contact me! :)
PEP 219 è di 9 anni e seriamente fuori moda. La difficoltà di "chiamare il codice Python dal codice C" è solo nell'implementazione discussa in PEP e non è in Stackless. Il nome di PEP ("Stackless Python") è un po 'improprio; ha tratto ispirazione da Stackless e basta. –