Entretien avec les développeurs Python francophones

Le 11 mars, nous vous proposions de poser des questions à des développeurs francophones du langage Python. Un peu occupés par leur participation à PyCon 2011, ils ont finalement trouvé le temps de vous répondre. Un grand merci à eux et à tous ceux qui ont posé les questions.

---

L'ensemble des réponses de l'entretien est en seconde partie et est placé sous licence Art Libre : cette œuvre est libre, vous pouvez la copier, la diffuser et la modifier selon les termes de la Licence Art Libre.

Sommaire

• Généralités
• Python 3
• Langage et cœur Python
• JIT, Implémentations alternatives
• Paquetage et écosysème

Généralités

Philippe Fremy: Qu'est ce que vous faites comme travail ? Est-ce que ça implique du Python ? Est-ce que vous êtes payés pour travailler sur le développement de Python ?

Victor: Je suis employé par EdenWall. Tous les outils sont écrits en Python : Twisted, XML-RPC, SSL pour la partie serveur, et PyQt pour la partie client. Guido Van Rossum (l'auteur de Python) est payé par Google pour travailler sur Python, et encore, je n'en suis pas sûr. De mon côté, je contribue à Python pendant mon temps libre (le soir ou la nuit :-)).

Antoine: Je suis travailleur indépendant. J'utilise la plupart du temps Python, mais il est rare d'être payé pour travailler sur Python. La plupart des contributeurs et développeurs sont bénévoles.

Tarek: Je suis développeur chez Mozilla. Je suis dans l'équipe Services, en charge du développement de serveurs applicatifs comme Firefox Sync. Tout est maintenant développé en Python coté serveur chez nous. Je ne suis pas payé pour travailler directement sur Python mais Mozilla couvre mes frais pour Pycon.

---

Philippe Fremy: Comment êtes-vous arrivés à devenir développeur Python ? Depuis combien de temps ?

Victor : J'ai testé de nombreux langages de programmation, et Python est tout simplement le meilleur. Aujourd'hui je ne code quasiment plus qu'en Python (juste un peu de C pour la gymnastique mentale). Cela fait environ cinq ans que je développe en Python, deux ans que je contribue à Python, et un an que je suis core developer (droit de commit).

Antoine : J'ai commencé à utiliser Python vers 2005, lorsqu'un client m'a confié une mission pour laquelle il privilégiait ce langage. C'est devenu mon langage préféré, et j'ai commencé à contribuer à l'interpréteur il y a trois ans.

Tarek : J'utilise Python depuis une petite dizaine d'années. Je me suis mis sérieusement au langage avec Zope en 2003/2004 pour la conception de portails de gestion de contenu chez Nuxeo. En 2008 je suis devenu contributeur pour essayer d'améliorer les outils de packaging (Distutils).

---

Python 3

Zarmakuizz: Il manque quoi pour une adoption massive de Python3 dans les distributions Linux ?

Antoine : Pas grand chose. Même Debian stable fournit Python 3.1.

Victor : À mon avis, Python 3.0 n'était pas prêt pour être utilisé. D'ailleurs, il a été "banni" dès que Python 3.1 est sorti. Et encore, vu le nombre de bugs corrigés dans Python 3.2, je pense que la bibliothèque standard de Python 3 n'était pas complètment utilisable avant la version 3.2. Ensuite, il faut d'abord que les bibliothèques majeures soient portées à Python 3 pour que les applications puissent migrer. Certains développeurs de bibliothèques sont de gros fainéants et attendent de voir ce que ça donne avec les autres bibliothèques. Aujourd'hui, un tiers des modules majeurs ont été portés à Python 3, il existe de nombreuses documentations et même un livre pour porter votre code vers Python 3. Vous avez de moins en moins d'excuses pour ne pas porter votre code vers Python 3. D'ailleurs, beaucoup de projets sont déjà compatibles Python 3 sans le savoir : un passage dans la moulinette 2to3 suffit.

Tarek : Comme dit Victor, nous n'avons pas atteint le point de basculement, où la majeure partie des bibliothèques sont disponibles sous Python 3. Mais rien d'alarmant : nous ne sommes pas en retard par rapport au calendrier initialement fixé qui prévoit encore plusieurs années. Je pense que 2013 sera l'année de Python 3.

---

Emmanuel C: En ce qui concerne l'écriture d'un nouveau projet, indépendamment des bugs et performances de l'interpréteur en lui-même, est-il raisonnable de partir sur Python V3 ? Je pense notamment à l'écosystème gravitant autour de Python, et à cette page qui met en exergue le fait que certains paquets importants n'ont toujours pas évolué vers Python V3.

Victor : Il n'y a aucun problème pour démarrer un nouveau projet en Python 3, c'est même conseillé : Python 2 est mort (il n'y a plus de nouvelles fonctionnalités ajoutées à Python 2, uniquement des corrections de bug). Python 3 est un meilleur langage que Python 2 (pour de nombreuses raisons), la bibliothèque standard est bien fournie, et de nombreux modules externes sont disponibles. Question performances, il me semble que Python 3 est aussi rapide, voir plus rapide dans certains cas, que Python 2. Mis à part quelques détails, la documentation et les livres existants sont encore valides pour Python 3. Il n'existe qu'une seule communauté Python. Pour les gros modules externes : si vous avez vraiment besoin d'un gros module qui n'est pas encore porté pour Python 3, je vous invite à aider au portage (ce n'est pas aussi difficile que ça en a l'air, c'est juste long sur de gros projets) !

Antoine : Oui, c'est plus que raisonnable. Si tu commences ton nouveau projet sur Python 2, tu devras te poser la question de porter ton code d'ici deux ou trois ans et tu perdras in fine du temps pour rien. Il faut se rappeler que la bibliothèque standard de Python fournit déjà beaucoup de fonctionnalités, et que de nombreuses bibliothèques majeures (comme PyQt, numpy ou SQLAlchemy) tournent désormais sous Python 3.

Tarek : Ça dépend du projet. Pour un projet web, je dirais non. Les BIBLIOTHÈQUES utiles dans ce cas ne sont pas toutes disponibles. Pour un projet scientifique, peut-être, vu que les bibliothèques du domaine le sont maintenant. À Mozilla nous restons sur Python 2, en partie à cause de WebOb.

---

Philippe Fremy: Le passage à Python 3 se fait de façon très lente, beaucoup de projets ne sont toujours pas portés. Est-ce un problème ? Est-ce que Python 3 apporte de réelles solutions ?

Victor : Il a été prévu par les développeurs de Python que la migration dure cinq ans. Vu la quantité de modules et projets disponible pour Python 3, je trouve que la migration se porte très bien, et même s'accélère. De toute façon, ce n'est aucunement un problème. Il n'est pas prévu de tuer Python 2 le plus vite possible, au contraire, Python 2 sera maintenu de longues années (aussi longtemps qu'il y aura des développeurs intéressés pour le faire). Il y a fort à parier que des développeurs refusent Python 3 (pour de bonnes ou mauvaises raisons) et continuent de fairer évoluer leurs projets pour Python 2. De mon côté, j'utilise 2to3 pour pouvoir distribuer mes projets pour Python 2 et 3 avec les même fonctionnalités. Une fois que 2to3 est mis en place (migration à Python 3), distribuer une version Python 3 a un coût nul (c'est fait automatiquement).

Antoine : Ce n'est pas plus lent que prévu. Le nombre de paquets officiellement disponibles pour Python 3 augmente régulièrement (cf. http://dev.pocoo.org/~gbrandl/py3.html), et c'est une sous-estimation car certains projets omettent de remplir les méta-données PyPI correctement.

Tarek : Je ne suis pas le genre à pousser pour Python 3. Python 2 est un language complet et suffisant, et Python 3 n'apporte aucune "killer feature" qui donne envie d'y passer. Nous serons tous naturellement sous Python 3 un jour car Python 2 aura lentement disparu, mais c'est tout :)

---

Tanguy Ortolo: Une distribution dont je tairais le nom avait pris la décision de faire de Python 3 son /usr/bin/python, causant d'évidents problèmes de compatibilité. Que pensez-vous de ce choix ?

Victor : J'ai l'impression que c'est un débat plutôt stérile, et ça ne m'intéresse pas. Si vous voulez en savoir plus, je vous laisse lire le fil de discussion récent (que j'ai ignoré) sur la liste python-dev : http://mail.python.org/pipermail/python-dev/2011-March/108491.html

Tarek : Bah. Les gens qui utilisent cette distribution sont habitués à des choix exotiques non ? ;)

---

Langage et cœur Python

GeneralZod: Maintenant que CPython 3.2 intègre les travaux d'Antoine sur le GIL (après plus d'un an de travail, chapeau !), quels sont les pistes pour améliorer les performances de Python dans un contexte multicore ? Si j'ai bien compris, on a désormais un GIL qui gère les changements de contexte de façon plus équitable et déterministe (basé sur des ticks et non plus sur l'exécution d'opcodes), mais pour autant ça ne résout pas tout les problèmes du GIL.

Le Cancre Las: Le GIL, quand est-ce qu'on l'enterre ?

Victor : Le module multiprocessing permet de faire du calcul parallèle sur plusieurs cœurs en utilisant plusieurs processus de manière transparente. Ce module existe depuis Python 2.7. Le nouveau module concurrent.futures permet de faire la même chose, mais indifféremment avec des processus ou des processus léger (avec la même API).

Questions performances, les progrès les plus importants ont été mesurés dans PyPy (trois fois plus rapide environ), un nouvel interprète qui utilise un compilateur à la volée moderne assez complexe, mais adapté à Python. Effectivement, le nouveau GIL améliore les performances dans le cas des processus légers. Pour rappel, de nombreuses fonctions implémentées en C relâchent le GIL, le temps de faire leur calcul intensif ou d'attendre des entrées/sorties (ex : calcul d'un hash, lecture depuis un fichier, socket réseau, …).

Je doute que le GIL disparaisse un jour de CPython pour des questions de rétro-compatibilité. La base de code de CPython (447.000 lignes de C, la partie Python étant pas ou peu impactée) et l'ensemble des extensions externes écrites en C supposent qu'il existe un GIL. Retirer le GIL demanderait probablement de modifier l'ensemble de la base de code, ainsi que toutes les extensions externes… Un travail titanesque. Des expériences passées ont montré un faible gain en terme de performance, mais c'était avant la généralisation des processeurs multi-cœurs. Par contre, le GIL est un "détail d'implémentation" (ahem, un gros détail, mais détail quand même) : Jython n'a jamais eu de GIL et est tout à fait capable d'exécuter plusieurs processus légers Python en parallèle (genre vraiment simultanément sur un processeur multi-cœurs).

Tarek : le GIL est un problème dans des cas très précis (CPU-Bound), mais n'est pas gênant pour la plupart des applis que les gens écrivent (I/O-Bound). Et les programmes qui font du calcul intensif utilisent des bibliothèques spécialisées qui sont écrites en majeure partie en C/C++ - et fournissent une interface Python. Je pense qu'on a trop focalisé sur le GIL et que d'autres choses sont plus importantes, comme la facilité d'attaquer des libs C avec ctypes, ou les outils comme cython qui permettent d'utiliser le C de manière presque transparente pour les calculs de tableaux. Enfin, comme le dit Victor, PyPy est LE projet prometteur en terme d'amélioration des performances.

---

Le Cancre Las: Le multi-threading potable au lieu des Usines à Gaz à la Twisted, c'est pour demain ?

Antoine : le multi-threading est potable justement, cela dépend du but recherché. S'il s'agit de mener des entrées / sorties en parallèle, le modèle de threading de Python est satisfaisant. S'il s'agit d'effectuer des calculs en parallèle, il ne l'est pas (sauf quelques bibliothèques sachant relâcher le GIL, comme hashlib). Quant à Twisted, c'est un moteur réseau puissant et extrêmement bien maintenu.

D'une manière générale, je pense que beaucoup de gens se font des soucis au sujet du GIL alors que la plupart des usages n'en sont pas affectés.

Victor : Twisted utilise des entrées-sorties asynchrones pour éviter le surcoût d'un ordonnanceur de processus (légers ou pas) : Twisted n'utilise pas de processus léger (mais il est possible d'en utiliser pour des longues tâches n'ayant pas d'API non bloquante). Il existe des bibliothèques asynchrones (syntaxe concise et claire) utilisant des coroutines plutôt que des callbacks (syntaxe assez lourde et débogage complexe) comme pyevent (greenlet). Les serveurs asynchrones ont fait leur preuve en terme de scalabilité (connexions simultanées et temps de réponse) et en performance (charge machine).

Tarek : J'aime beaucoup GEvent, qui rend la programmation asynchrone assez lisible par rapport à Twisted. Gevent permet aussi de rendre le module socket coopératif en le patchant, ce qui permet de rendre des programmes synchrones qui appellent les sockets, asynchrones sans aucune modification du code, ce qui est assez bluffant. Et ça marche ! on a constaté un gain de 25% sur un de nos projets rien qu'en basculant sur Gevent (couplé a NGinx + GUnicorn).

---

GeneralZod : Au niveau de la bibliothèque standard, Python 3.2 arrive avec les futures qui semblent faire consensus (adopté par les langages mainstreams comme Java, C++0x, C#, etc …) et un nouveau namespace concurrent qui ouvre la porte à pas mal d'améliorations : conteneurs concurrent-friendly, threading haut-niveau (des compréhensions de listes de haut niveau, etc …), etc. De ce côté-là, la roadmap semble plus claire, mais concrètement, qu'est-ce qui arrive dans le tuyau ?

Victor : J'ai répondu un peu plus haut au sujet du calcul parallèle. Question nouveauté dans ce domaine : rien n'est prévu dans l'interprète ou la bibliothèque standard. Mais rien n'empêche d'étendre Python avec des modules externes (greenlet en étant un très bon exemple).

---

cho7: J'ai pas trop suivi l'actualité pythonesque récente, vous êtes-vous enfin décidés à laisser l'opérateur % tranquille ou bien êtes-vous toujours déterminés à le faire disparaître au profit de la fonction format() ? Les deux devraient pouvoir cohabiter !

Antoine : un certain nombre de core développeurs veulent laisser l'opérateur % tranquille, il a donc probablement encore de longues années à vivre !

Victor : Bien que la syntaxe "format % arguments" ait été marquée comme dépréciée (c'est peut-être encore le cas), il n'est pas prévu de supprimer cette syntaxe. De manière générale, il est très rare que des fonctions et que des syntaxes soient supprimées dans des versions mineurs de Python. Perso, je pratique les deux syntaxes (str.format et str%args), je n'arrive pas à me décider pour l'une ou l'autre.

Tarek : Je dois être un vieux car je n'utilise que %. Je trouve l'autre illisible :)

---

Philippe Fremy: En lisant python-dev, j'ai pu apprécier le travail de Victor sur la gestion de l'unicode sur tout ce qui touche à la gestion de fichiers. Si j'ai bien suivi, il reste des cas insolubles où on ne pourra pas afficher correctement le nom d'un fichier, voire où on ne pourra pas lire un fichier au nom étrange ?

Victor : Au contraire. La PEP 383 ajoute un gestionnaire d'erreur Unicode ("surrogateescape") à Python 3.1 pour gérer n'importe quel type de fichier, et surtout les noms de fichiers "invalides" (séquence d'octets ne pouvant pas être décodés depuis la locale de l'utilisateur). Python 3.2 améliore énormément le support des noms de fichier invalides (la plupart des modules, voir tous, ont été corrigés). Python 3.3 améliorera encore légèrement ce point, pour permettre de charger des modules Python ayant un nom non-ASCII (import héhé ne fonctionne actuellement qu'avec une locale UTF-8, et donc pas sous Windows). Pour en savoir plus, vous pouvez regarder la vidéo de ma conférence Status of Unicode in Python 3 qui a eu lieu à Pycon US il y a quelque jours à peine.

---

GeneralZod : Python, appuyé de frameworks web de qualité (Pylons, TG, Django etc …) connaît un grand succès en tant que langage web. Le passage de WSGI à Python 3 semble traîner depuis quelques temps notamment à cause du choix du type de données pour les flux (unicode ou bytes, ou selon le contexte), où en est-on ? Est-ce que la bibliothèque standard verra un jour son support de WSGI enrichi et qu'on puisse enfin se débarrasser de modules à moitié maintenus (mais que tout le monde utilise) comme Flup ?

Victor : C'est un peu le bordel. Différentes équipes se tapent dessus pour imposer leur point de vue, et aucun consensus n'a été trouvé. Guido van Rossum a utilisé de son pouvoir en tapant du point sur la table et a tranché en validant la PEP 3333 (un peu avant la sortie de Python 3.2) qui est -en gros- une simple mise à jour de la PEP 333 pour Python 3. Cette PEP n'est pas idéale, mais permet d'utiliser WSGI avec Python 3. Le module cgi (utilisé par WSGI) a été patché dans Python 3.2 pour améliorer la distinction octets/caractères. Pour les détails et dernières actualités, allez lire les archives de la liste de diffusion web-sig.

Tarek : Il faut être pragmatique sur l'évolution de WSGI, et PEP 3333 est à mon avis le bon choix. Ça va débloquer les situations et permettre le portage de WebOb par exemple.

---

Philippe Fremy: Certains projets comme KDE donnent un accès svn facilement (au second patch soumis). D'autres comme gcc ou CentOs n'ouvrent le repository qu'après plusieurs années de travail et sous recommendation. Comment se situe Python de ce point de vue là ? Est-ce difficile de passer de contributeur à développeur, d'obtenir un accès svn (hg maintenant) ? Est-ce que vous pensez que le curseur est au bon niveau ?

Antoine : Non, c'est relativement aisé. En général, lorsqu'un contributeur a fourni entre cinq et dix patches de bonne qualité, l'un d'entre nous se décide à le proposer comme core développeur, et il n'y a presque jamais de refus. Ainsi, en 2010, 20 nouveaux core développeurs ont été intégrés.

Notre problème est plutôt d'attirer des contributeurs, c'est pour cela que nous avons récemment écrit un guide que nous encourageons tout le monde à lire : http://docs.python.org/devguide/

Victor : J'ai mis deux ans à obtenir mon droit de commit, certains développeurs ont attendu quelques mois. Avoir le droit de commit sur la partie C prend plus de temps car ça demande d'être plus prudent et de maitriser les subtilités, dans le code C, de Python comme le comptage des références. De manière générale, on recherche des développeurs qui s'investissent sur la durée car ils devront maintenir le code que seuls eux maitrisent. Ça arrive souvent que quand une personne s'attaque à un sujet, elle devienne experte, puis doive maintenir cette partie à son insu (Alexander Beloposky est par exemple notre expert et donc le nouveau mainteneur de la gestion du temps).

Tarek : Les choses ont beaucoup évolués. De nos jours, il suffit d'être présent physiquement à un sprint et avoir un mentor, pour devenir contributeur sur une partie précise de Python. Là ou moi ou Victor avons mis du temps à obtenir ce droit.

---

Philippe Fremy: La transition vers mercurial, ça donne quoi ? Ça marche ? Est-ce que vous avez rencontré des limitations de mercurial au passage ? Corrigeables ou éternelles ?

Victor : C'est vraiment tout frais, je suis frustré de ne pas encore avoir fait mon premier commit Mercurial dans CPython. J'ai été pris de court juste avant de partir à Pycon US, je n'ai pas eu le temps de me faire aux nouvelles pratique ("forwardport" entre les différentes versions, au lieu de backports, ex: 3.2->3.3 au lieu de 3.3->3.2) Mais j'ai profité de Mercurial pour créer ma branche (unicode_import) quand j'étais en déplacement. J'ai pu la publier dans un dépôt "expérimental" (différent du dépôt principal) sur hg.python.org. Ceci n'est pas nouveau, il existait déjà des branches expérimentales (comme py3k-cdecimal) avec Subversion. Mercurial est un nouvel outil, pour le moment on l'utilise comme Subversion. Mercurial ouvre la porte pour de nouvelles façons de contribuer, expérimenter et travailler en équipe.

Antoine : Cela marche, oui. Le dépôt principal est disponible à http://hg.python.org/cpython/

Il n'y a pas de gros souci pour l'instant. Nous avons deux légères insatisfactions :

1) la difficulté de porter des patches entre deux branches indépendantes (en pratique, entre Python 3.x et Python 2.7): on ne peut pas utiliser "hg merge", et "hg import" comme "hg transplant" écrivent les rejets dans des fichiers séparés au lieu de les intégrer aux fichiers modifiés avec des marqueurs de conflits.

2) l'inspection des modifications après un merge, notamment par "hg status", est imparfaite. Or notre mode de développement (avec quatre branches de maintenance, et l'obligation pour chaque développeur de fusionner lui-même ses commits) implique énormément de merges (http://hg.python.org/cpython/graph/tip), et toute aide serait la bienvenue. Le bug que j'ai rapporté ne semble pas rencontrer l'adhésion des développeurs de Mercurial : http://mercurial.selenic.com/bts/issue2705

Tout ceci est corrigeable, ce sont des problèmes d'interface utilisateur.

Tarek Pour moi c'est un réel soulagement car Python etait le seul projet sur lequel je contribue qui était encore sur un système non distribué. Le nombre de fois où j'ai tenté un "hg st" sur Python est incalculable. Mercurial est vraiment bien pour travailler avec des gens qui n'ont pas les droits de commits, il suffit de cloner et de faire une pull request Les difficultés. Après le problème c'est de merger les clones, on peut parfois se retrouver avec un historique pollué de "merge", si on a pas pris le soin d'utiliser mq ou rebase.

---

rewind: J'ai l'impression que personne n'utilise les mêmes conventions de nommage et que même à l'intérieur de la lib standard, il y a plusieurs conventions. N'est-ce pas un handicap à son adoption, surtout quand on voit Ruby ou Java qui ont des conventions fortes et respectées à peu près partout ?

Victor : Il existe une convention pour le langage C (la PEP 7 pour CPython) et le code Python (PEP 8). On a profité de Python 3 pour uniformiser ça justement. Par contre, en dehors de l'interpète et de la bibliothèque standard, c'est un peu le far west. Chacun est libre d'utiliser la convention de son choix (ou plus rigolo, ne pas utiliser de convention), bien que la PEP 8 soit vivement conseillée. Peut-être qu'il faudrait qu'on monte des milices menant des actions coup de poings ? Personnellement, je suis peu attaché aux conventions : bien que ça aide pour le travail collaboratif, ce n'est pas le critère le plus important pour moi. Mais je me force à m'y conformer.

Antoine : La bibliothèque standard a 20 ans pour certains modules. La PEP 8 (http://www.python.org/dev/peps/pep-0008/) est utilisée dans tous les modules récents, mais certains modules précèdent son écriture et ont leur propre style (comme unittest avec ses célèbres assertPrédicat).

Tarek : C'est historique. Les APIs publiques non-PEP8 par exemples ne vont pas être changées juste pour ça. Ce serait beaucoup de problèmes pour pas grand chose. Tout nouveau code est PEP 8 par contre. Et bon… la PEP 8 dit bien que toute modification sur un module existant doit respecter en premier le style du module, même si ce style n'est pas PEP 8.

---

Philippe Fremy: Qu'est ce que vous pensez de la qualité du code actuel de Python ? Pour le passage à Python 3, vous avez pu changer quelques trucs mais aucun changement majeur interne n'était prévu. Est-ce qu'il y a des zones de code où vous vous dite "il faudrait carrément tout réécrire ce truc mais c'est pas possible du tout" ?

Victor : Je connais surtout le code C. Pour avoir lu le code de nombreux autres projets libres écrits en C, je trouve le code C de CPython très propre et facile à lire. Le code de la bibliothèque standard écrite en Python est parfois ancien et n'utilise pas toujours les dernières fonctionnalités ou convention, mais globalement le code Python est bien écrit. Bien sûr, on conserve une bonne proportion de code très laid que personne ne veut plus toucher pour alimenter le troll (un troll étant connu pour son appétit), sauf qu'exprès on le cache.

Antoine : Le code augmente constamment en qualité (à la fois l'interpréteur et la bibliothèque standard) ainsi que la couverture de tests. Il y a eu une baisse de qualité lors de Python 3.0, à cause de la profondeur des modifications apportées, mais on s'est repris avec Python 3.1 et la version 3.2 récemment sortie est encore plus fignolée.

Pour donner une idée, voici le nombre de lignes de code (comptées avec sloccount de David Wheeler) dans la suite de tests, à savoir le répertoire "Lib/test": -> python 2.4.6: 61170 -> python 2.5.5: 75517 -> python 2.6.6: 100237 -> hg, branche 2.7 (la future 2.7.2): 116655 -> hg, branche default (la future 3.3): 126239

Pour ce qui est de la question du code "moisi", à savoir les vieux trucs qui mériteraient d'être réécrits, c'est vrai qu'il y en a. Témoin distutils, qui va bientôt avoir un successeur nommé "packaging" beaucoup plus moderne et complet sur lequel travaille Tarek. J'ai moi-même fait beaucoup progresser le module SSL dans Python 2.7 comme dans Python 3.2, il est maintenant compatible avec des exigences raisonnables de sécurité. Lorsque les APIs sont mal fichues, c'est difficile à corriger pour des raisons de compatibilité, mais il est toujours possible d'ajouter de meilleures APIs tout en continuant à supporter les anciennes.

Il y a eu aussi un effort récemment sur les buildbots, avec une vingtaine de machines différentes tournant sous des OS et architectures variés. Neuf d'entre elles sont considérées comme stables, et ne sont pas censées montrer d'erreurs avant une release (on peut les voir par exemple ici : http://www.python.org/dev/buildbot/all/waterfall?category=3.2.stable) ; malheureusement les tests ne sont pas tous très robustes et il y a donc des erreurs sporadiques.

Tarek : Distutils est miteux. J'ai commencé à le corriger, mais ce travail va être fait dans packaging un nouveau paquet Python qui arrive dans 3.3. Et on va laisser distutils moisir dans son coin. Avec la stdlib c'est toujours le même problème: une fois une API publique en place, elle y est pour toujours ! Donc les modifications sont délicates.

---

Philippe Fremy: Est-ce que le langage Python a encore besoin d'évoluer ? Le langage est aujourd'hui très complet, est-ce qu'il y a vraiment besoin de lui rajouter des nouveaux trucs ? Le moratorium sur l'immobilité du langage a été levé, est-ce une bonne chose selon vous ?

Victor : Bien que le langage Python soit parfait (on ne peut plus rien supprimer), je suis surpris d'apprécier les ajouts récents comme le mot clé with ou la méthode str.format. Maintenant, j'ai l'impression que le langage est quand même très stable et de nombreuses propositions de modifications sont rejetées (allez faire un tour dans les PEP et la liste de diffusion Python-ideas), après discussion argumentée bien sûr. Python a toujours été réputé pour sa bibliothèque standard, et celle-ci continue d'évoluer. Par exemple, je trouve les "nouveaux" modules multiprocessing et io assez impressionnants. Je vous conseille aussi de voir l'entretien avec Guido Van Rossum à qui on a posé la même question lors du dernier PyCon US.

Antoine : Pour moi, il n'y aurait effectivement rien à ajouter dans l'immédiat. Ceci dit, la PEP 380 (http://www.python.org/dev/peps/pep-0380/) a de fortes chances d'être implémentée dans Python 3.3 car plusieurs core développeurs la soutiennent : elle ajoute la construction "yield from" qui permet de faciliter l'écriture de coroutines, au prix d'une certaine complexité sémantique sous-jacente (cf. http://www.python.org/dev/peps/pep-0380/#formal-semantics).

Tarek : Python est un langage complet. Les nouveautés/améliorations à venir sont mineures. Le vrai combat est dans la stdlib maintenant.

---

Troy McClure: Quel est selon vous le point faible de python, le domaine sur lequel il est le plus en retard / handicapé ? (genre multithreading, performances, indentation etc)

Victor : Python est clairement novateur en matière d'indentation et les Perleux n'ont cesse de baver face à cette débauche de lisibilité. Au niveau handicap, il me semble que les compilateurs à la volée JavaScript sont très avancés, et il est temps que PyPy se démocratise. Son compilateur à la volée n'a rien à envier aux dernières implémentations de JavaScript. Par contre, je suis déçu qu'il n'y ait que PyPy comme implémentation alternative de Python possédant un compilateur à la volée. Unladen Swallow étant au point mort et Google ne semble pas très motivé pour relancer ce projet. Il est important que Python ait plusieurs implémentations, car ça permet d'innover (PyPy est le projet qui a le plus expérimenté et le résultat en vaut la chandelle).

Antoine : Je pense qu'il faut plus regarder du côté des plateformes et de l'adoption. Par exemple, Javascript a du succès uniquement parce qu'il bénéficie d'une plateforme captive. PHP est extrêmement répandu pour des raisons historiques.

Les performances et le multithreading sont à mon avis de faux problèmes (j'ai expliqué plus haut en ce qui concerne le GIL). Python, PHP et Ruby démontrent que les performances sont relativement secondaires face aux qualités (fussent-elles toutes relatives et temporaires) d'une plateforme.

Un défaut lancinant à l'heure actuelle est la gestion de paquets : mais cela va s'améliorer avec le nouveau module "packaging", qui sera disponible en backports sous le nom "distutils2". À côté de cela, il reste de multiples imperfections qui sont le lot de tout système en évolution organique : cela se corrige en améliorant régulièrement la bibliothèque standard, en corrigeant les bugs, etc.

Tarek : Le packaging est souvent décrié, mais les gens ne se rendent pas forcément compte qu'on est pas plus en retard que les autres langages. Essayez de faire du packaging avec PHP et Ruby, et vous verrez que vous rencontrerez autant de problèmes, voir plus.

Pour moi, les défauts principaux de Python sont: un mauvais marketing, une mauvaise promotion et une doc moyenne. Regardez Python.org ou PyPI et comparez les avec des sites équivalents dans les autres langages. Quand je débarque sur python.org, j'ai le droit à un texte compact illisible, là où je voudrai un exemple de code, des liens mis en avant sur la doc. Je trouve la page d'accueil du langage GO excellente. Je trouve la notre horrible.

La documentation s'est améliorée grâce à Sphinx, mais elle reste moyenne comparée à l'excellente doc de PHP. Il y a un manque d'interaction.

NB: Django fait mieux que Python

Enfin, en terme de marketing, on pourrait mieux faire.

Je sais, c'est facile à dire, et je ne contribue pas dans ces domaines-là mais je pense qu'il y a beaucoup à faire.

---

Philippe Fremy: Est-ce qu'il y a des choses qui manquent réellement à Python, ou qui demandent une grosse amélioration, dans l'écosystème Python en général ?

Antoine : Pas vraiment, je dirais même que la montée en popularité de Python est un peu surprenante face à l'absence totale d'effort de publicité (voire l'aspect quelque peu désuet et bricolo du site Web). C'est frappant en ce qui concerne PyCon, la conférence annuelle en Amérique du Nord, qui commence à devenir une petite usine.

Victor : Avec le temps, je pense que le principal critère de choix d'un langage est sa communauté. La communauté Python est ouverte et très active. Il existe des groupes d'utilisateurs dans plusieurs pays. Il y a par exemple l'AFPy en France (Belgique, Suisse et Maroc) et Python Montréal à Montréal (qui vient d'obtenir l'organisation de PyCon 2014 et 2015).

Tarek c.f. question précédente et aussi un meilleur PyPI.

---

JIT, Implémentations alternatives

Philippe Fremy: Que pensez-vous des efforts pour avoir des interpréteur Python JIT ? Vous y croyez pour le futur de Python ? Unladen Swallow devait rentrer dans Python, sauf que le projet est l'arrêt. Vous pensez qu'il a encore une chance de rentrer, maintenant que PyPy l'a rattrappé en terme de performance ?

djano: Est-ce que CPython est toujours le maître incontesté des interpréteurs Python? Où en sont les implémentations alternatives à CPython? Est ce que le moratorium sur l'immobilité du langage a porté ses fruits? i.e. est ce que les implémentations alternatives à CPython ont pu rattraper leur retard?

Le Cancre Las: PyPy à la place de CPython en standard, utopie ?

Emmanuel C: On voit beaucoup en ce moment de nouvelles concernant l'amélioration fulgurante des performances de Javascript (SpiderMonkey dans Firefox, V8 dans Chrom[e|ium]). En ce qui concerne Python, j'aurai voulu savoir si les performances de l'interpréteur étaient actuellement jugées "bonnes" ou "mauvaises", si des travaux d'optimisation étaient envisageables, envisagées, ou si certaines particularités de la syntaxe empêchaient une optimisation massive de l'interpréteur.

Victor : PyPy est compatible avec CPython à 99,9%, a une empreinte mémoire plus faible et est plus rapide. Avec le passage à Python 2.7, je pense que PyPy est prêt pour la production.

Unladen Swallow de son côté est mal parti car c'est un projet financé par Google, et Google semble s'être désintéressé du projet. Ses deux développeurs qui s'en occupaient ne travaillent plus dessus et il semble que personne ne se sente capable de reprendre le projet. Je crois qu'il existe une PEP et une branche Subversion pour intégrer le travail d'Unladen Swallow (utilisation de LLVM notamment) dans CPython. Des parties les plus simples comme les optimisations du module cpickle ont déjà été intégrées.

Je considère que le moratoire sur Python 3.2 est une bonne idée, bien que ça n'ait pas été suffisant pour que PyPy, IronPython ou Jython migrent à Python 3. Ces implémentations alternatives ont déjà assez à faire côté optimisation et migration vers Python 2.7. L'équipe de PyPy dit par exemple très clairement qu'ils se concentrent sur l'optimisation et ne souhaitent pas s'occuper de passer à Python 3. CPython reste pour le moment l'implémentation Python de référence oui.

Antoine : difficile de dire si j'y crois ou pas. PyPy a de bons résultats, mais je ne pense pas que l'existence d'une JIT conditionne le succès ou non de Python. Par ailleurs PyPy a des défauts que je trouve assez rédhibitoires : absence de docs, code très mal commenté, système de compilation désastreux (il n'y a pas de compilation incrémentale : la moindre modification et il faut relancer le bousin pendant 30 minutes). On verra d'ici un an ou deux si la hype autour de PyPy se confirme ou retombe. Je pense que beaucoup de gens vont se rendre compte que le sujet des performances n'est pas primordial.

Quant à Unladen Swallow, j'avais personnellement assez peur de l'entrée dans le coeur de CPython d'une base importante de code C++ (je ne parle pas de LLVM, mais bien de la JIT Unladen Swallow) avec ses propres idiomes. D'un côté, il est dommage que le projet soit à l'arrêt (et à mon avis il n'est pas près de redémarrer), d'un autre côté il est possible que son intégration nous aurait occasionné pas mal de travail supplémentaire.

L'utilisation d'une implémentation alternative ne se justifie que s'il y a un besoin réel. CPython est certainement l'implémentation la mieux débuggée, la mieux testée, la mieux documentée, celle sur laquelle le plus de bibliothèques tierces sont supportées. Vouloir passer sous PyPy simplement parce que c'est plus rapide me semble un peu futile.

Concernant les performances de CPython, elles peuvent être vues comme "mauvaises" face à l'état de l'art des compilateurs JIT, si l'on considère l'exécution de code purement calculatoire. Mais relativement "bonnes" malgré tout si l'on prend en compte l'existence d'accélérateurs natifs pour beaucoup de tâches (parsing XML et JSON, par exemple), ainsi que le soin apporté aux conteneurs standard comme les dictionnaires.

Ce n'est pas la syntaxe qui complique les travaux d'optimisation mais la sémantique. En particulier, le modèle objet de Python est extrêmement riche. Il faut remarquer que PyPy, qui donne aujourd'hui de bons résultats, existe depuis plus de cinq ans avec pendant plusieurs années des développeurs payés à temps plein sur subvention de l'Union Européenne. C'est un boulot très conséquent.

Tarek : PyPy ! PyPy ! PyPy !

---

MadHatter: Je me demande, ne serait-il pas possible de concevoir un compilateur Python (tout en gardant l'interpréteur bien entendu) ?

Victor : Réponse courte : non. Il existe des compilateurs C et C++ pour des sous-ensembles du langage Python, mais l'introspection et la possibilité de modifier des objets et classes à la volée empêchent d'avoir un compilateur efficace. PyPy trace dynamiquement l'exécution du programme pour choisir quelles parties doivent être compilées à la volée, et annote le type des variables. Avec la connaissance des types, on peut se permettre des optimisations beaucoup plus intéressantes.

Antoine : S'il s'agit d'un compilateur "à l'avance", avec uniquement de l'analyse statique de code, des expérimentations passées n'ont pas donné de résultats intéressants. Il y a un projet récent, "Nuitka" (http://kayhayen24x7.homelinux.org/blog/nuitka-a-python-compiler/) qui semble encourageant bien qu'on manque de résultats concrets sur de vrais benchmarks (autres que pystone).

Dans l'absolu, un compilateur JIT est beaucoup plus prometteur en termes de performance car il permet de réduire le dynamisme de Python au runtime, mais c'est un développement complexe pour les raisons évoquées plus haut.

---

Philippe Fremy: Qu'est ce que vous pensez de Perl 6 ? Est-ce que vous l'avez regardé ? Est-ce qu'il y a des idées qui pourraient être utilisées dans Python aussi ?

Barret Michel: On a tendance à voir Perl et Python comme deux frères « ennemis » empruntant chacun une voie diamétralement opposée, qu'en pensez-vous ? Y a-t-il des communication entre les deux projets ou une inspiration de l'un à l'autre ? (même s'il est clair que l'énorme majorité des fonctionnalités de l'un ne peuvent aller dans l'autre et vice versa)

Victor : Je pense que c'est le même langage, mais qu'il est toujours agréable de pouvoir troller sur leur seule différence qui est la syntaxe. Il est clair que les syntaxes sont diamétralement opposées : Perl vise la concision en reposant sur l'implicite, Python vise l'expressivité (facilité de relecture) en exige l'explicite (voir la table des 19 commandements, import this). Bien sûr, les développeurs Perl vieillissant, la race va s'éteindre. Fort heureusement, il existe de nombreux autres trolls comme les performances ridicules de Python ou son indentation (tabs, 2, 3 ou 4 espaces d'ailleurs ? 8 espaces ? allez, on va dire tabs et espaces).

En tout cas, Perl 6 ressemble de plus en plus à Python, ce qui est une bonne chose :-) J'espère que Parrot va être un succès, bien que pour l'instant j'ai plutôt entendu parler de soucis de performances. Le logiciel libre gagnerait beaucoup à avoir un concurrent à Mono. Peut-être que PyPy pourrait devenir un nouvelle machine virtuelle générique, mais je n'ai pas entendu parler d'implémentation de Perl pour PyPy. Les mondes Perl et Python semblent malheureusement hermétiques, mis à part l'événement OSDC.fr.

Antoine : Non, je ne l'ai pas regardé. Il est clair que Perl fait office de repoussoir pour n'importe quel développeur sensible à l'esthétique de Python ainsi qu'à ses principes de conception. Quant à Perl 6, c'est là aussi l'antinomie de ce qu'a décidé Guido pour Python 3 : à savoir corriger les défauts les plus marquants tout en conservant la majorité du code existant. Le résultat, c'est que Python 3 est fonctionnel et utilisable depuis deux ans, et que son utilisation grimpe avec une adoption grandissante aussi bien chez les nouveaux venus que chez les développeurs Python chevronnés.

Cela ne veut pas dire qu'il y ait la moindre inimitié : Parrot, la VM de Perl 6, tire son nom d'une blague entre Larry Wall et Guido van Rossum; et Allison Randal, l'architecte de Parrot, est membre de la Python Software Foundation. Mais les inspirations de Perl dans Python sont à peu près inexistantes, à part pour les expressions régulières.

Tarek : Je vous invite a lire le comparatif de Yoda. Écrit il y a des années, il reste d'actualité ;)

---

Paquetage et écosysème

sifu: Sur le packaging Python, la dernière fois que j'avais regardé, la situation était un peu complexe. Il me semblait que Tarek Ziadé (un autre dév. français) travaillait là dessus (http://guide.python-distribute.org/). Est-ce que la situation s'est éclaircie ?

Emmanuel C: Est-ce qu'on pourrait avoir un état des lieux des systèmes de gestion de paquets disponibles sur Python, avec les outils associés ? J'ai toujours eu un peu cette impression que c'était "le bordel"… Est-ce toujours le cas, par exemple ? Par là, j'entend : est-ce qu'une utilisation non triviale d'un outil personnalisable est envisageable au jour le jour ?

Le Cancre Las: Distutil 2, un anneau pour les gouverner tous ?

Victor : Oui, distutils2 va être intégré à Python 3.3 sous le nom packaging, et une version compatible Python 2.4-3.2 va être distribuée. distutils2 est rétro-compatible avec l'ensemble des autres projets (de setuptools à pip en passant par distutils) et permet par exemple de (enfin !) désinstaller un programme ou lister les modules installés.

Tarek : C'est toujours le bordel mais la lumière arrive dans Python 3.3. Je ne peux pas m'étendre sur le sujet, ça boufferait toute l'interview. Je vous invite à lire mon blog et à mater cette vidéo de Pycon—elle explique bien ce que je suis en train de faire—: http://blip.tv/file/4880990 [anglais]

---

Le Cancre Las: A quand un vrai toolkit graphique pythonique au lieu des wrappers tout moisis (TK, Qt, GTK, FOX, SWT, …) ?

Victor : Ça existe déjà et ça s'appelle le web, non ? :-) Sinon pour info, PySide 1.0 est sorti, je n'ai pas encore eu le temps d'y jetter un œil.

Antoine : il y a PyGUI, je ne sais pas ce que ça vaut : http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

---

neerd: Sinon une question à nos amis dév: Que pensent-ils de la sortie des Python Tools for Visual Studio par Microsoft ? (http://pytools.codeplex.com/)

Victor : Ah enfin ! Moi qui attendait depuis de si longues années de pouvoir à nouveau travailler sous Windows, je trouve Vi tellement fade ! Plus sérieusement, ils ont l'air d'avoir des fonctionnalités avancées pour MPI et le web (intégration de Django si je me souviens bien). Je suis également content qu'ils distribuent ça sous licence libre, et encore plus content que IronPython ne soit pas mort après que Microsoft ait cessé de financer ce projet. Comme dit précédemment, je pense qu'il est important d'avoir des implémentations alternatives.

Antoine : si Microsoft pense nécessaire de sortir ces outils, c'est qu'il y a une demande. Une part importante des utilisateurs de Python utilise Windows : les installeurs Windows pour Python 3 reçoivent plusieurs centaines de milliers de téléchargements par mois.

---

Philippe Fremy: La popularité de Python a vraiment augmenté ces dernières années, est-ce que vous en avez vu les conséquences au niveau du développement du langage : plus de bugs reportés ? plus de patchs ? plus de contributeurs ? plus de questions débiles ?

Victor : Je n'ai pas l'impression que l'utilisation de Python ait explosée ces dernières années, mais plutôt que ça augmente doucement mais sûrement. Maintenant, je n'ai pas trop regardé les statistiques. Par contre, à la vue du bug tracker : il y a de plus en plus de nouveaux tickets. Les personnes participant au bug tracker sont généralement compétentes et réactive, et ça fait avancer le projet. Sur IRC et les listes de diffusion, il y a parfois des questions "débiles", mais je suis toujours étonné qu'il y ait au moins une personne répondant poliment, alors qu'il est tellement plus tentant de se moquer ou répondre sèchement ! Il y a de plus en plus de documentation de Python, notamment pour apprendre, donc pas de soucis pour les débutants. Il suffit de leur pointer la bonne doc et ils vont lire tranquillement.

Antoine : au niveau du nombre de commits et de core développeurs actifs, la courbe est clairement ascendante. Il y a aussi plus de 50 bugs rapportés par semaine (dont les trois quarts environ sont de vrais problèmes ou demandes d'amélioration). Quant au nombre de patches et de contributeurs, il semble également augmenter, mais c'est moins facilement quantifiable.

Ce qui impacte aussi le nombre de patches et de contributeurs, c'est notre capacité à encaisser le choc, à traiter les patches en attente et à les intégrer s'ils sont prêts. C'est donc un processus de longue haleine, car pour augmenter cette capacité à traiter les patches, il faut augmenter le nombre de core développeurs et donc d'abord le nombre de contributeurs !

---

antistress: Les développeurs Python travaillent ils majoritairement sous OS libre ? Si oui, est-ce dû au fait que le code est nécessairement ouvert avec Python ?

Victor : Bien que je développe uniquement sous Linux, je dois régulièrement effectuer des vérifications sous Windows, m'assurer que je ne casse rien. Il m'est arrivé de toucher Mac OS X, mais je vous rassure, je me suis protégé. Certains bossent même sur AIX, mais c'est une autre histoire. J'ai l'impression que la grosse majorité des core developer Python développent sous Linux. Le reste doit se distribuer équitablement entre Windows et Mac. En dehors des core developers, je ne sais pas ce qu'il en est. Par contre, il est important pour les core developers d'offrir une excellente portabilité. Les systèmes les mieux supportés sont Linux, Windows, Mac OS X et FreeBSD. Le support FreeBSD est légèrement moins bon dans certains cas tordus (ex : quelques soucis avec les signaux, en cours de correction).

Antoine : majoritairement sous Linux et Mac OS X, mais je ne connais pas le décompte précis (donc impossible de dire si les OS libres prévalent). Nous avons quelques développeurs sous Windows, probablement pas assez au vu des problèmes spécifiques à cette plateforme.

La répartition est, je pense, culturelle : les développeurs Windows sont moins habitués à contribuer à des projets libres. Aussi, quelqu'un qui s'intéresse à un projet libre comme Python finit par s'intéresser aux OS libres. Enfin, développer sous Windows un outil qui s'utilise principalement en ligne de commande n'est pas très agréable. Le terminal Windows est rudimentaire.

Tarek : Je bosse sous Linux sur mon MacBook Pro, parce que, aussi bien pour mon taf que pour Python, c'est la plate-forme reine pour le développement. Je suis sous Ubuntu mais je garde une partition Mac OS X avec reFit pour pouvoir utiliser Omnigraffle—il n'existe aucun outil aussi bien sous Linux --. Mais c'est la seule raison: sérieusement, vous avez déjà essayé d'installer Graphviz avec Macports ?

Aller plus loin

• Python (175 clics)
• PyCon (148 clics)