Quels sont les inconvénients de Stackless Python? [fermé]


127

J'ai lu récemment sur Stackless Python et il semble avoir de nombreux avantages par rapport à cPython vanilla. Il a toutes ces fonctionnalités intéressantes comme la récursivité infinie, les microthreads, les continuations, etc. et en même temps est plus rapide que cPython (environ 10%, si l' on en croit le wiki Python ) et compatible avec lui (au moins les versions 2.5, 2.6 et 3.0).

Tout cela semble presque trop beau pour être vrai. Cependant, TANSTAAFL , je ne vois pas beaucoup d'enthousiasme pour Stackless parmi la communauté Python, et PEP 219 n'a jamais vu le jour. Pourquoi donc? Quels sont les inconvénients de Stackless? Quels squelettes sont cachés dans le placard de Stackless?

(Je sais que Stackless n'offre pas de réelle concurrence, juste un moyen plus simple de programmer de manière simultanée. Cela ne me dérange pas vraiment.)

Réponses:


165

Je ne sais pas d'où vient ce "Stackless est 10% plus rapide" sur le Wiki, mais là encore je n'ai jamais essayé de mesurer ces performances. Je ne peux pas penser à ce que fait Stackless pour faire une si grande différence.

Stackless est un outil incroyable avec plusieurs problèmes organisationnels / politiques.

Le premier vient de l'histoire. Christian Tismer a commencé à parler de ce qui est finalement devenu Stackless il y a environ 10 ans. Il avait une idée de ce qu'il voulait, mais avait du mal à expliquer ce qu'il faisait et pourquoi les gens devraient l'utiliser. C'est en partie parce que son arrière-plan n'avait pas la formation CS concernant des idées comme les coroutines et parce que ses présentations et ses discussions sont très axées sur la mise en œuvre, ce qui est difficile pour quiconque n'est pas déjà à la mode dans les continuations pour comprendre comment l'utiliser comme solution pour leurs problèmes.

Pour cette raison, la documentation initiale était médiocre. Il y avait quelques descriptions sur la façon de l'utiliser, avec le meilleur de contributeurs tiers. A PyCon 2007, j'ai donné une conférence sur " Utiliser Stackless " qui s'est plutôt bien passée, d'après les chiffres de l'enquête PyCon. Richard Tew a fait un excellent travail pour les collecter, mettre à jour stackless.com et maintenir la distribution lorsque de nouvelles versions de Python apparaissent. Il est un employé de CCP Games , les développeurs d'EVE Online, qui utilise Stackless comme élément essentiel de leur système de jeu.

Les jeux CCP sont également le plus grand exemple du monde réel que les gens utilisent lorsqu'ils parlent de Stackless. Le tutoriel principal pour Stackless est " Introduction à la programmation simultanée avec Stackless Python " de Grant Olson , qui est également orienté jeu. Je pense que cela donne aux gens une idée faussée que Stackless est axé sur les jeux, alors que c'est plutôt que les jeux sont plus facilement orientés vers la continuation.

Une autre difficulté a été le code source. Dans sa forme originale, il a fallu des changements dans de nombreuses parties de Python, ce qui a rendu Guido van Rossum, le chef de file de Python, méfiant. Une partie de la raison, je pense, était la prise en charge de call / cc qui a été supprimée plus tard comme étant "trop ​​semblable à la prise en charge d'un goto quand il existe de meilleurs formulaires de niveau supérieur". Je ne suis pas certain de cet historique, alors lisez simplement ce paragraphe comme suit: "Stackless nécessitait trop de changements".

Les versions ultérieures n'ont pas nécessité les modifications, et Tismer a continué à faire pression pour son inclusion dans Python. Bien qu'il y ait eu quelques considérations, la position officielle (pour autant que je sache) est que CPython n'est pas seulement une implémentation Python, mais il est conçu comme une implémentation de référence, et il n'inclura pas la fonctionnalité Stackless car il ne peut pas être implémenté par Jython ou Iron Python.

Il n'y a absolument aucun projet de " changements significatifs de la base de code ". Cette citation et cet hyperlien de référence d'Arafangion (voir le commentaire) datent d'environ 2000/2001. Les changements structurels ont été effectués depuis longtemps, et c'est ce que j'ai mentionné ci-dessus. Stackless tel qu'il est maintenant est stable et mature, avec seulement des modifications mineures de la base de code au cours des dernières années.

Une dernière limitation avec Stackless - il n'y a pas de fervent défenseur de Stackless. Tismer est maintenant profondément impliqué dans PyPy , qui est une implémentation de Python pour Python. Il a implémenté la fonctionnalité Stackless dans PyPy et la considère bien supérieure à Stackless lui-même, et estime que PyPy est la voie du futur. Tew maintient Stackless mais il n'est pas intéressé par le plaidoyer. J'ai envisagé de jouer ce rôle, mais je ne voyais pas comment je pourrais en tirer un revenu.

Mais si vous souhaitez vous entraîner à Stackless, n'hésitez pas à me contacter ! :)


39

il a fallu beaucoup de temps pour trouver cette discussion. À ce moment-là, je n'étais pas sous PyPy mais j'avais une liaison de 2 ans avec psyco, jusqu'à ce que la santé arrête tout cela assez brusquement. Je suis à nouveau actif et je conçois une approche alternative - je la présenterai sur EuroPython 2012.

La plupart des déclarations d'Andrews sont correctes. Quelques ajouts mineurs:

Stackless était nettement plus rapide que CPython, il y a 10 ans, car j'ai optimisé la boucle d'interprétation. À ce moment-là, Guido n'était pas prêt pour cela. Quelques années plus tard, les gens ont fait des optimisations similaires et encore plus et de meilleures, ce qui rend Stackless un peu plus lent, comme prévu.

Concernant l'inclusion: eh bien, au début, j'étais très insistant et convaincu que Stackless est la voie à suivre. Plus tard, quand il était presque possible d'être inclus, j'ai perdu tout intérêt pour cela et j'ai préféré le laisser ainsi, en partie par frustration, en partie pour garder le contrôle de Stackless.

Les arguments comme "les autres implémentations ne peuvent pas le faire" me semblaient toujours boiteux, car il existe d'autres exemples où cet argument pourrait également être utilisé. J'ai pensé que je ferais mieux d'oublier cela et de rester en bonne amitié avec Guido, ayant ma propre distribution.

Pendant ce temps, les choses changent à nouveau. Je travaille sur PyPy et Stackless en tant qu'extension J'en parlerai parfois plus tard

Acclamations - Chris


5

Si je me souviens bien, Stackless devait être inclus dans le CPython officiel, mais l'auteur de stackless a dit aux gens de CPython de ne pas le faire, car il prévoyait d'apporter des modifications significatives à la base de code - vraisemblablement il voulait que l'intégration soit faite plus tard lorsque le projet était plus mature.


1
La source? Je trouve cela intéressant, mais je ne peux évidemment pas vous croire simplement parce que vous l'avez dit. J'aurais l'air idiot si vous aviez tort et j'ai commencé à dire à quel point c'était intéressant.
Devin Jeanpierre le

2
Excellent point. Désolé, je n'ai pas la référence, car c'était dans une conversation irc en #python sur freenode, mais j'ai réussi à trouver une ancienne conversation de liste de diffusion sur gnosis.cx/download/charming_python_10_outtakes.html qui donne beaucoup plus d'informations sur le situation.
Arafangion

Ce lien est vraiment génial. Cela répond à beaucoup de mes questions.
Ryszard Szopa le

Ce lien a 8 ou 9 ans (il parle de Python 2.1) et toute discussion sur les changements futurs de la base de code a eu lieu depuis longtemps. Stackless Python est stable et mature, et il n'y a pas de plans pour «des changements significatifs dans la base de code».
Andrew Dalke

Dalke: Telle est la façon dont les choses se passent - s'il y a eu des changements substantiels dans les décisions d'intégration des changements, n'hésitez pas à proposer une référence plus récente, mais je soupçonne que cette ancienne source que j'ai fournie n'a fait que commencer la tendance à avoir des variantes séparées de python, par exemple, JPython, IronPytion ..
Arafangion

3

Je suis également intéressé par les réponses ici. J'ai joué un peu avec Stackless et il semble que ce serait un bon ajout solide à Python standard.

PEP 219 mentionne des difficultés potentielles lors de l'appel du code Python à partir du code C, si Python souhaite passer à une pile différente. Il devrait y avoir des moyens de détecter et d'empêcher cela (pour éviter de détruire la pile C). Je pense que cela est traitable, donc je me demande également pourquoi Stackless doit être autonome.


3
PEP 219 a 9 ans et est sérieusement obsolète. Les difficultés d '«appeler du code Python à partir du code C» ne se trouvent que dans l'implémentation discutée dans le PEP, et pas dans Stackless. Le nom du PEP ("Stackless Python") est un peu trompeur; il s'est inspiré de Stackless et c'est tout.
Andrew Dalke le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.