Python pour .Net ressuscite d'entre les morts

Le développement sur IronPython, une implémentation Python qui s'exécute sur le Common Language Runtime (CLR) du framework .Net, obtient un coup de pouce grâce au projet qui a récemment changé de main pour un nouveau responsable du développement.

Jeff Hardy, ancien développeur principal d'IronPython, a confirmé la transition sur la liste de diffusion des utilisateurs d'Ironpython au début du mois. «Pour de nombreuses raisons, je n'ai tout simplement pas le temps pour le moment d'accorder à IronPython l'attention qu'il mérite», a écrit Hardy, «alors je cède le contrôle du projet à [d'autres contributeurs du projet] Alex Earl et Benedikt Eggers.»

Un Python pour .Net, et vice versa

IronPython, écrit en C #, n'est pas uniquement destiné à exécuter des programmes Python standard. Il peut fournir aux programmeurs Python un pont vers les applications et objets .Net existants. Mieux encore, ces objets peuvent être importés et traités avec la même syntaxe et les mêmes idiomes que les objets Python natifs.

Le développement sur IronPython a incontestablement ralenti au cours des deux dernières années. La dernière version majeure était pour Python 2.7.5, fin 2014. Python 3 n'était pas pris en charge par IronPython - un inconvénient majeur puisque Python 2 ne sera plus pris en charge à partir de 2020, et Python 3 est le successeur établi.

Lors d'une réunion sur le site de discussion des développeurs, Gitter, Earl, Eggers et d'autres ont analysé les problèmes les plus urgents auxquels le projet est confronté à mesure qu'il avance: que faire pour les problèmes IronPython en suspens sur CodePlex; quel type de calendrier de diffusion mettre en œuvre; et quel type de feuille de route concevoir pour IronPython 3.

Un autre problème soulevé lors des discussions était de savoir comment implémenter la prise en charge des bibliothèques Python utilisant des extensions C. Si IronPython doit avoir le public le plus large possible, ce n'est pas une option. De nombreuses bibliothèques Python majeures, comme Numpy, utilisent des extensions C pour la vitesse, et elles devraient idéalement fonctionner telles quelles dans IronPython sans avoir besoin d'être recompilées.

La bonne nouvelle est que certains travaux ont déjà été effectués dans ce domaine, à savoir Ironclad, un projet conçu pour permettre aux extensions CPython compilées de fonctionner telles quelles dans IronPython. La mauvaise nouvelle est que le projet n'a pas connu beaucoup de travail depuis longtemps et devra être fortement révisé pour être utile pour Python moderne.

De rubis et de GIL

Un autre problème qui s'est posé était de savoir comment gérer un projet similaire géré par la même équipe: IronRuby, qui est une implémentation .Net de Ruby, comme son nom l'indique. Les deux langages ont été co-développés, car ils sont issus des mêmes efforts au sein de Microsoft autour du Dynamic Language Runtime, et sont restés très proches après que Microsoft les a transformés en efforts communautaires en 2010.

Le plan est de faire d'IronRuby son propre projet pour attirer son propre public de développeurs. IronPython 2 continuera également à être développé en tant que projet discret.

Le développement futur d'IronPython pourrait s'avérer fructueux en fournissant un moyen de réaliser le rêve de longue date d'un environnement d'exécution Python rapide et convivial pour plusieurs cœurs. IronPython ne dispose pas de Global Interpreter Lock (GIL), une fonctionnalité de nombreuses implémentations Python qui a été accusée d'être un obstacle à la haute performance.

Cela dit, le fait qu'IronPython n'ait pas de GIL ne le rend pas automatiquement plus rapide; certains benchmarks IronPython sont meilleurs que CPython, mais d'autres sont nettement pires. Pour l'instant, simplement mettre IronPython à niveau avec les branches actuelles de Python, 2 et 3, devrait être une mission suffisante.