¿Cuáles son los inconvenientes de Stackless Python?
python-stackless (4)
He estado leyendo recientemente sobre Stackless Python y parece tener muchas ventajas en comparación con cPython vainilla. Tiene todas esas características geniales como recursión infinita, microthreads, continuaciones, etc. y al mismo tiempo es más rápido que cPython (alrededor del 10%, si se cree que la wiki de Python ) y es compatible con ella (al menos las versiones 2.5, 2.6 y 3.0).
Todo esto parece casi demasiado bueno para ser verdad. Sin embargo, TANSTAAFL , no veo mucho entusiasmo por Stackless entre la comunidad de Python, y PEP 219 nunca ha llegado a realizarse. ¿Porqué es eso? ¿Cuáles son los inconvenientes de Stackless? ¿Qué esqueletos están escondidos en el armario de Stackless?
(Sé que Stackless no ofrece simultaneidad real, solo una manera más fácil de programar de forma concurrente. Realmente no me molesta).
No sé de dónde vino ese "Stackless es 10% más rápido" en el Wiki, pero nunca he intentado 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 eventualmente 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 formación no tuvo la formación de CS sobre ideas como coroutines y porque sus presentaciones y discusiones están muy orientadas a la implementación, lo cual es difícil para alguien que todavía no está inmerso en las continuidades comprender cómo usarlo como una solución para sus problemas.
Por esa razón, la documentación inicial fue pobre. Hubo algunas descripciones de cómo usarlo, con lo mejor de terceros contribuyentes. En PyCon 2007 pronuncié una charla sobre " Using Stackless ", que fue bastante bien, según los números de la encuesta de PyCon. Richard Tew ha hecho un gran trabajo recopilando estos, actualizando stackless.com y manteniendo la distribución cuando surgen nuevos lanzamientos de Python. Es un empleado de CCP Games , los 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 que la gente usa en el mundo real cuando hablan de Stackless. El principal tutorial para Stackless es Grant Olson, " Introducción a la programación simultánea con Stackless Python ", que también está orientado 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 son orientados a la continuación más fácilmente.
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, tuviera cuidado. Parte de la razón, creo, fue el soporte para call / cc que luego se eliminó por ser "demasiado parecido a apoyar un goto cuando hay mejores formas de alto nivel". No estoy seguro acerca de este historial, así que solo lea este párrafo como "Stackless solía requerir demasiados cambios".
Los lanzamientos posteriores no requirieron los cambios, y Tismer continuó presionando para su inclusión en Python. Si bien hubo algunas consideraciones, la postura oficial (que yo sepa) es que CPython no es solo una implementación de Python, sino que se trata de una implementación de referencia, y no incluirá la funcionalidad Stackless porque no puede ser implementada por Jython. o Iron Python.
No hay absolutamente ningún plan para " cambios significativos en la base de códigos ". Esa cita y el hipervínculo de referencia de Arafangion (ver el comentario) son de aproximadamente 2000/2001. Los cambios estructurales se han hecho hace mucho tiempo, y es lo que mencioné anteriormente. Stackless como es ahora es estable y maduro, con solo pequeños ajustes a 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 del futuro. Tew mantiene Stackless pero no está interesado en la defensa. Consideré estar en ese papel, pero no pude ver cómo podría obtener un ingreso de eso.
Aunque si quieres entrenar en Stackless, ¡no dudes en contactarme ! :)
Si no recuerdo mal, Stackless estaba programado para su inclusión en el CPython oficial, pero el autor de stackless le dijo a la gente de CPython que no lo hiciera, porque planeaba hacer algunos cambios significativos en la base del código, presumiblemente quería que la integración se realizara más tarde cuando el proyecto fue más maduro.
También estoy interesado en las respuestas aquí. He jugado un poco con Stackless y parece que sería una buena adición sólida al Python estándar.
PEP 219 menciona las posibles dificultades para llamar al código Python desde el código C, si Python desea cambiar a una pila diferente. Tendría que haber formas de detectar y prevenir esto (para evitar la destrucción de la pila C). Creo que esto es manejable, así que también me pregunto por qué Stackless debe mantenerse por sí misma.
llevó bastante tiempo encontrar esta discusión. En ese momento no estaba en PyPy, pero tuve una aventura de 2 años con psyco, hasta que la salud detuvo todo esto abruptamente. Ahora estoy activo nuevamente y estoy diseñando un enfoque alternativo: lo presentaré en EuroPython 2012.
La mayoría de las declaraciones de Andrews son correctas. Algunas adiciones menores:
Stackless fue significativamente más rápido que CPython, hace 10 años, porque optimicé el ciclo del intérprete. En ese momento, Guido no estaba listo para eso. Unos años más tarde, la gente hizo optimizaciones similares e incluso más y mejores, lo que hace que Stackless sea un poco más lento, como se esperaba.
Sobre la inclusión: bueno, al principio fui muy insistente y convencido de que Stackless es el camino a seguir. Más tarde, cuando era casi posible incluirme, perdí interés en eso y preferí dejarlo así, en parte por frustración, parcialmente para mantener el control de Stackless.
Los argumentos como "otras implementaciones no pueden hacerlo" me parecieron siempre difíciles, ya que hay otros ejemplos en los que también podría usarse este argumento. Pensé que sería mejor que me olvidara de eso y mantuviera una buena amistad con Guido, teniendo mi propia distribución.
Mientras tanto, las cosas están cambiando nuevamente. Estoy trabajando en PyPy y Stackless como una extensión. Hablaremos de eso a veces más tarde
Saludos - Chris