No sé de dónde vino ese "Stackless es un 10% más rápido" en el Wiki, pero nunca he tratado de medir esos números de rendimiento. No puedo pensar en lo que hace Stackless para hacer una diferencia tan grande.
Stackless es una herramienta increíble con varios problemas organizativos / políticos.
El primero viene de la historia. Christian Tismer comenzó a hablar sobre lo que finalmente se convirtió en Stackless hace unos 10 años. Tenía una idea de lo que quería, pero le costaba explicar lo que estaba haciendo y por qué la gente debería usarlo. Esto se debe en parte a que su experiencia no tenía la capacitación de CS sobre ideas como las corutinas y porque sus presentaciones y debates están muy orientados a la implementación, lo que es difícil para cualquier persona que aún no esté a la altura de las continuaciones para comprender cómo usarlo como una solución para sus problemas.
Por esa razón, la documentación inicial era deficiente. Hubo algunas descripciones de cómo usarlo, con lo mejor de terceros contribuyentes. En PyCon 2007 di una charla sobre " Uso de Stackless " que funcionó bastante bien, según los números de la encuesta de PyCon. Richard Tew ha hecho un gran trabajo recolectando estos, actualizando stackless.com y manteniendo la distribución cuando surgen nuevos lanzamientos de Python. Es empleado de CCP Games , desarrolladores de EVE Online, que utiliza Stackless como parte esencial de su sistema de juego.
Los juegos CCP también son el ejemplo más grande del mundo real que las personas usan cuando hablan de Stackless. El tutorial principal para Stackless es la " Introducción a la programación concurrente con Python apilable " de Grant Olson , que también está orientada al juego. Creo que esto le da a la gente una idea sesgada de que Stackless está orientado a los juegos, cuando es más que los juegos están más orientados a la continuación.
Otra dificultad ha sido el código fuente. En su forma original, requirió cambios en muchas partes de Python, lo que hizo que Guido van Rossum, el líder de Python, desconfiara. Creo que parte de la razón fue el soporte para call / cc que luego se eliminó por ser "demasiado parecido a soportar un goto cuando hay mejores formas de nivel superior". No estoy seguro de este historial, así que solo lea este párrafo como "Stackless solía requerir demasiados cambios".
Las versiones posteriores no requirieron los cambios, y Tismer continuó presionando para su inclusión en Python. Si bien hubo cierta consideración, la postura oficial (hasta donde yo sé) es que CPython no es solo una implementación de Python, sino que se entiende como una implementación de referencia, y no incluirá la funcionalidad Stackless porque Jython no puede implementarla o pitón de hierro.
No hay absolutamente ningún plan para " cambios significativos en la base del código ". Esa cita e hipervínculo de referencia de Arafangion (ver el comentario) son de aproximadamente 2000/2001. Los cambios estructurales se han hecho durante mucho tiempo, y es lo que mencioné anteriormente. Stackless como es ahora es estable y maduro, con solo pequeños ajustes en la base de código en los últimos años.
Una limitación final con Stackless: no hay un gran defensor de Stackless. Tismer ahora está profundamente involucrado con PyPy , que es una implementación de Python para Python. Ha implementado la funcionalidad Stackless en PyPy y la considera muy superior a Stackless, y siente que PyPy es el camino hacia el futuro. Tew mantiene Stackless pero no está interesado en la defensa. Pensé en desempeñar ese papel, pero no podía ver cómo podía obtener ingresos de él.
Aunque si quieres entrenar en Stackless, ¡no dudes en contactarme ! :)