Actualités Python : PyPy 1.2, distutils2, vidéos de Pycon 2010, Python 2.7

Posté par  (site web personnel) . Modéré par Bruno Michel.
Étiquettes :
20
15
mar.
2010
Python
Quelques brèves au sujet du langage Python :

  • PyPy 1.2 inclut enfin un compilateur à la volée
  • Inclusion d'Unladen Swallow dans CPython repoussée
  • distutils, setuptools, distribute et distutils2
  • Python 2.6.5RC2, 3.1.2RC1 et 2.7alpha3
  • Vidéos des conférences Pycon US 2010
  • Revues de presse hebdomadaire de l'AFPy
  • AFPyros sur Paris

Détails en seconde partie de la dépêche. Interprètes alternatifs : PyPy 1.2, inclusion d'Unladen Swallow et benchmarks

Le projet PyPy est un interprète Python écrit en Python. La version 1.2 inclut pour la première fois un compilateur à la volée (JIT), uniquement compatible x86 (IA-32) pour le moment (fonctionne sur x86-64 avec le mode de compatibilité 32 bits). Cette version met donc l'accent sur la vitesse, tout en conservant une excellente compatibilité avec l'implémentation Python de référence (CPython, écrite en C). PyPy sans JIT consomme moins de mémoire que CPython, par contre le JIT consomme beaucoup de mémoire. La prochaine version devrait résoudre ce problème. Lire Introducing the PyPy 1.2 release pour en savoir plus.

Unladen Swallow est un autre projet, soutenu par Google, visant à accélérer Python, mais ayant une approche différente. Unladen Swallow est un fork de Python 2.6 qui rajoute un compilateur à la volée basé sur LLVM. Son inclusion dans CPython a été proposée. Mais Unladen Swallow modifie beaucoup de code et surtout rajoute des dépendances sur le langage C++ et le projet LLVM. Aucun compromis n'a été trouvé pour le moment, et une PEP est en cours d'écriture : PEP 3146: Merging Unladen Swallow into CPython. Une solution serait de proposer le compilateur à la volée comme extension (optionnelle).

Pour comparer les performances entre tous les interprètes Python, un projet benchmarks a été monté. PyPy a d'ailleurs monté le site speed.pypy.org pour afficher l'évolution des performances de son interprète (avec et sans JIT) par rapport à CPython 2.6.

Changements du côté de distutils, setuptools, distribute et distutils2

Quiconque ayant essayé d'installer un projet Python a été confronté à distutils ou setuptools (ou au plus récent distribute, fork de setuptools). Ces outils sont surtout réputés pour leur complexité ou leurs problèmes (ex: on ne peut pas désinstaller un programme installé par distutils !). Alors que setuptools a été développé en dehors de Python sans réelle volonté d'améliorer Python (d'améliorer distutils sur lequel il repose), les efforts actuels visent à se recentrer sur Python et tenter d'uniformiser tous les systèmes d'installation. Les changements passent par « Propositions d'amélioration de Python » (PEP en anglais) :
  • PEP 345 (Metadata for Python Software Packages 1.2)
  • PEP 376 (Changing the .egg-info structure)
  • PEP 386 (Changing the version comparison module in Distutils)

Un sprint a été organisé lors du Pycon US 2010 sur distutils. Tarek Ziadé (l'initiateur, français, du projet distribute et le nouveau mainteneur de distutils, bref celui qui fait avancer le schmilblick) a écrit un long article pour détailler les développements et faire le point sur la situation actuelle : The fate of Distutils – Pycon Summit + Packaging Sprint detailed report. Le module distutils ne va pas être modifié pour conserver la compatibilité. Par contre, le nouveau module distutils2 va concentrer toutes les avancées dans le domaine. Enfin, un guide a été écrit pour expliquer simplement comment packager un projet Python : The Hitchhiker’s Guide to Packaging.

Nouvelles versions Python : Python 2.7 se prépare

Pas de grosse version majeure à court terme, uniquement des corrections de bugs : sortie de Python 2.6.5RC2 (What’s New in Python 2.6, Changelog) et 3.1.2RC1 (What’s New In Python 3.1). Le gros chantier est la version 2.7 qui sera la dernière de la série Python 2.x. La version 2.7 finale est prévue pour fin juin 2010. En attendant, une version 2.7alpha3 permet déjà de tester la longue liste de nouveautés. La version 2.7 doit servir de passerelle de Python2 vers Python3 : de nombreuses fonctionnalités ont été portés de Python3 vers Python2 (ex: les dictionnaires ordonnés, odict). La version 2.7 risque d'être maintenue beaucoup plus longtemps que les autres versions 2.x, le temps de la migration vers Python3.

Vidéos des conférences Pycon US 2010

Pycon US 2010 a eu lieu à Atlanta du 17 au 25 février : 2 jours de tutoriels, 3 jours de conférences, pour finir avec 4 jours de sprint. Les vidéos des conférences sont visionables sur blip.tv.

Association Francophone Python : Python WAW et AFPyros

Pour se tenir au courant de l'actualité Python, l'Association Francophone Python (AFPy) propose une revue de presse Python semaine par semaine : Python WAW.

L'AFPy organise régulièrement des « AFPyros » sur Paris, soirée conviviale pour parler de Python dans un bar. Ils sont souvent organisés à l'arrache : mieux vaut suivre la liste de diffusion des membres ou le salon IRC #afpy (sur le serveur Freenode) pour ne pas les rater !

Enfin, pour les utilisateurs d'IRC : rendez-vous sur le salon #python-fr du serveur Freenode pour troller Python (lenteur, consommation mémoire, indentation et autres drolleries) ou y poser vos questions.

Aller plus loin

  • # Vitesse

    Posté par  (site web personnel) . Évalué à 6.

    Je suis impressionné par les performances de PyPy 1.2 telles qu'elles apparaissent sur la page de bench : http://speed.pypy.org/overview/
    J'ai l'impression que le jit a complètement changé la donne à ce niveau.
    Est-ce qu'il est envisageable que PyPy devienne l'implémentation de référence ?

    • [^] # Re: Vitesse

      Posté par  (site web personnel) . Évalué à 10.

      J'ai l'impression que le jit a complètement changé la donne à ce niveau. Est-ce qu'il est envisageable que PyPy devienne l'implémentation de référence ?

      Unladen Swallow utilise un JIT et semble également plus rapide que CPython. Bien qu'Unladen Swallow soit un "simple" fork de CPython, le merge a été refusé (cf. ma dépêche).

      PyPy est un tout nouveau projet écrit depuis zéro. Bien qu'il soit compatible Python, il est conçu complètement différement de CPython. D'ailleurs, il est écrit en RPython (et Python) en non pas en C. Il n'est donc pas question de le merger dans CPython.

      Pour que PyPy devienne l'implémentation de référence, il faudrait qu'il soit apprécié par les utilisateurs puis tellement populaire qu'il rende CPython désuet. Or PyPy semble encore peu utilisé en production, voir pas du tout. Un ami m'a par exemple dit que le module distutils de PyPy est complètement bogué, or il est hyper important pour Python : sans ça, PyPy est inutilisable.

      Même si PyPy devient populaire, CPython et PyPy risquent de coexister très longtemps. Le mieux qui puisse se produire serait d'arriver à détacher la bibliothèque standard Python du projet CPython pour que ça devienne un projet à part entière. CPython sera un interprète tout nu. CPython, PyPy, Jython, Unladen Swallow, IronPython, ... utiliseraient tous la même bibliothèque standard plutôt que chacun utilise sa propre bibliothèque plus ou moins patchée dans son coin.

      CPython est l'implémentation de référence mais aussi celle qui apporte les nouveautés du langage et de la bibliothèque standard. Ça pose d'ailleurs problème : chaque implémentation est plus ou moins bien compatible avec CPython. CPython est par exemple la seule implémentation de Python3 ! Un moratoire a été voté pour interdire les modifications du langage (mais pas de la bibliothèque standard), ce qui devrait permettre à Python3 d'être adopté plus rapidement, et aux autres implémentations d'arriver au même niveau que CPython. Si CPython évolue sans arrêt, les autres implémentations n'arriveront jamais au même niveau.

      J'espère que ma longue réponse t'aura un peu éclairé :-)

      • [^] # Re: Vitesse

        Posté par  (site web personnel) . Évalué à 2.

        Merci beaucoup pour les précisions.

      • [^] # Re: Vitesse

        Posté par  . Évalué à 5.

        Dans ta dépêche, tu as oublié un élément-clé : un certain Victor Stinner a obtenu les droits de commit et va pouvoir casser les buildbots sans demander la permission à personne :)

      • [^] # Re: Vitesse

        Posté par  (site web personnel) . Évalué à 2.

        L'autre proposition qui a il me semble été acceptée est d'avoir toujours maintenant une implémentation en pur python de tous les modules C de la stdlib python.

        Cela permettra à toutes les implémentations de python d'utiliser la stdlib. C'est un autre aspect qui fait que les implémentations de python alternatives restaient à la ramasse.

        Si aujourd'hui, il est difficile de concevoir que les implémentations alternatives de Python deviennent aussi populaire que CPython, on peut en tout cas dire que GvR s'en donne les moyens.

        Cela dit, ça résoudra pas la situation des numpy, PyQt et autres modules python en C.

        • [^] # Re: Vitesse

          Posté par  (site web personnel) . Évalué à 4.

          Cela permettra à toutes les implémentations de python d'utiliser la stdlib. C'est un autre aspect qui fait que les implémentations de python alternatives restaient à la ramasse.

          PyPy a recodé énormément de modules en pur Python. Par contre, l'implémentation native est toujours plus rapide.

          Cela dit, ça résoudra pas la situation des numpy, PyQt et autres modules python en C.

          ctypes est maintenant intégré à Python et PyPy l'utilise. Ca permet d'écrire des bindings en pur Python qui fonctionnent sur plusieurs implémentations de Python (notamment CPython et PyPy).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.