Tu as raison sur le fond pour les modules d'extensions: ils ont été conçus pour s'interfacer avec CPython (dans un temps immémorable où CPython n'était que l'unique implémentation de Python) et pas du tout pour être indépendants de l'implémentation. Notamment, le durée de vie des objets, même dans les modules d'extensions, est gérée par le comptage de référence, c'est à dire par le Garbage Collector de CPython.
Etre compatible avec CPython veut dire fonctionner avec le Garbage Collector de CPython ou gérer ça de façon très astucieuse. C'est ce qu'a fait PyPy, en proposant un modèle mixte pour les modules d'extension. Si je me souviens bien, ils utilisent le encore le ref-counting mais c'est le Garbage Collector classique qui collecte les objets une fois les références épuisées. Donc on y est presque (c'est le module cpyext), mais apparemment, toute l'API CPython n'est pas implémentée.
Pyston veut aussi conserver la compatibilité totale avec les extensions, avec des bidouilles autour du refcounting. Leurs plans sont malheureusement très théoriques et il faudra attendre qu'ils s'y mettent pour savoir si leur approche tient la route.
Pour résoudre ce problème de fond, les auteurs de PyPy ont écrit (bien avant PyPy) deux modules d'interfaçage avec des bibliothèques: ctypes et maintenant cffi. Les deux permettent d'appeler très facilement, sans compilation, des bibliothèques dynamiques. Ca résoud un cas majeur d'utilisation des modules d'extensions, à savoir interfacer des libs existantes écrites en C. Cffi est compatible avec PyPy, et bientôt avec Jython. On peut donc espérer à terme réduire la surface du problème.
Côté CPython, un effort a été fait pour réduire le nombre de symboles CPython exposés, afin de proposer une compatibilité plus simple avec CPython. L'objectif est plus modeste, permettre la compatibilité des modules d'extensions avec plusieurs versions de CPython en même temps.
[^] # Re: Modules d'extension
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un projet de VM Python chez Dropbox et état des lieux des autres VM. Évalué à 5.
Tu as raison sur le fond pour les modules d'extensions: ils ont été conçus pour s'interfacer avec CPython (dans un temps immémorable où CPython n'était que l'unique implémentation de Python) et pas du tout pour être indépendants de l'implémentation. Notamment, le durée de vie des objets, même dans les modules d'extensions, est gérée par le comptage de référence, c'est à dire par le Garbage Collector de CPython.
Etre compatible avec CPython veut dire fonctionner avec le Garbage Collector de CPython ou gérer ça de façon très astucieuse. C'est ce qu'a fait PyPy, en proposant un modèle mixte pour les modules d'extension. Si je me souviens bien, ils utilisent le encore le ref-counting mais c'est le Garbage Collector classique qui collecte les objets une fois les références épuisées. Donc on y est presque (c'est le module cpyext), mais apparemment, toute l'API CPython n'est pas implémentée.
Pyston veut aussi conserver la compatibilité totale avec les extensions, avec des bidouilles autour du refcounting. Leurs plans sont malheureusement très théoriques et il faudra attendre qu'ils s'y mettent pour savoir si leur approche tient la route.
Pour résoudre ce problème de fond, les auteurs de PyPy ont écrit (bien avant PyPy) deux modules d'interfaçage avec des bibliothèques: ctypes et maintenant cffi. Les deux permettent d'appeler très facilement, sans compilation, des bibliothèques dynamiques. Ca résoud un cas majeur d'utilisation des modules d'extensions, à savoir interfacer des libs existantes écrites en C. Cffi est compatible avec PyPy, et bientôt avec Jython. On peut donc espérer à terme réduire la surface du problème.
Côté CPython, un effort a été fait pour réduire le nombre de symboles CPython exposés, afin de proposer une compatibilité plus simple avec CPython. L'objectif est plus modeste, permettre la compatibilité des modules d'extensions avec plusieurs versions de CPython en même temps.