Entretien avec les développeurs Python francophones

Posté par (page perso) . Modéré par Lucas Bonnet.
66
16
avr.
2011
Python

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

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 ?

  • # Francophonie

    Posté par . Évalué à 2.

    Comme on est plusieurs, « francophone » est censé être au pluriel (titre + corps de la dépêche). Sinon, merci pour les questions, assez intéressantes dans l'ensemble !

  • # Merci !

    Posté par (page perso) . Évalué à 4.

    Merci pour ces interviews très intéressantes !

  • # Distutils

    Posté par (page perso) . Évalué à 7.

    Super entretien, très intéressant, et qui m'a permis de découvrir plusieurs projets.
    C'est une très bonne chose de travailler sur distutils (et la désinstallation !), et ce serait bien que ça pousse à sortir quelques outils (notamment pour la recherche de paquets).
    pip partait dans la bonne voie, notamment en évitant les installations partielles ou en allant chercher les paquets sur des dépôts mercurial.
    J'espère que ça va mener certains projets à revoir leur installation: wxpython par exemple n'est pas installable via distutils/distribute/pip, et du coup la gestion de dépendance automatique est complexe, ce qui peut rebuter à installer des projets.

    Je vais jeter un œil à la présentation mentionnée.

    PS: et j'ai du mal à comprendre les critiques de Twisted: c'est une pure merveille, et l'équipe est réactive et agréable.

    • [^] # Re: Distutils

      Posté par (page perso) . Évalué à 4.

      ce serait bien que ça pousse à sortir quelques outils (notamment pour la recherche de paquets)

      À ce que j'en ai compris, distutils2 ("packaging") est livré avec un outil pysetup qui permet de lister les paquets installés (entre autres, ça peut faire plein de trucs). Sinon y'a une API simple pour faire la même chose. Si pysetup répond déjà à tous les besoins, je ne suis pas sûr qu'il soit encore nécessaire d'avoir plusieurs outils (incompatibles ?) pour cette tâche. J'espère d'ailleurs que pip va fusionner avec distutils2 (il me semble que c'est bien parti pour).

      wxpython par exemple n'est pas installable via distutils/distribute/pip

      distutils2 ne résoud pas tous les problèmes. Un projet comme wxPython est autrement plus compliqué à packager qu'un petit projet ayant juste un fichier Python, notamment car il doit être compilé, a sûrement des dépendances non-Python, et le binaire résultant est spécifique à un OS (voir à une version précise de l'OS). Les distributions Linux ont déjà de super outils pour packager tout et n'importe quoi. Sous Mac OS X et Windows, il faut tout faire soit même.

      j'ai du mal à comprendre les critiques de Twisted

      Perso, c'est la syntaxe des callbacks qui me dégoûte. C'est difficile à écrire et encore plus difficile à déboguer (surtout les errbacks !).

  • # Python vs Ruby

    Posté par . Évalué à 4.

    Ca parle beaucoup de comparaisons entre Python et Perl mais j'aurais aussi bien aimé avoir leurs avis sur Ruby car pour moi lorsque je me pose une question sur l'utilisation d'un langage de script j'écarte d'emblée Perl à cause de sa syntaxe. Ensuite entre Python et Ryby mon coeur balance

    • [^] # Re: Python vs Ruby

      Posté par (page perso) . Évalué à 4.

      Si tu parles anglais, tu peux jeter un œil ici: http://www.wikivs.com/wiki/Python_vs_Ruby , c'est un wiki qui ne fourni que de comparaisons sensées être objectives de diverses technologies/choses.
      Après, sauf quelques cas et préférences particuliers, je pense que les 2 se valent, le choix AMHA devrait plutôt se porter sur les bibliothèques autour dont tu pourrais avoir besoin.

    • [^] # Re: Python vs Ruby

      Posté par . Évalué à 7.

      Et bien je peux te donner mon avis, car j'ai hésité longuement entre Python et Ruby,
      la raison de la longueur de l'hésitation est que les deux langages sont vraiment très intéressants.
      Je dirais que la seule grosse différence est que la syntaxe de Ruby est plus concise tout en restant logique (mais elle évolue assez souvent ce qui est un point faible à mon avis pour la maintenance) tandis que celle de Python est plus verbeuse mais aussi plus facile a apprendre (mais il vient d'y avoir une évolution majeure ce qui est aussi un problème).

      Donc si tu es un débutant un programmation: prends Python.
      Si tu es un confirmé et que tu pratiques le shell et le Perl(beurk), Ruby sera peut-être une évolution plus naturelle..
      Mais je dirai qu'à ce moment là ce qui compte le plus c'est l'état des librairies que tu vas utilisé pour tes besoins et non pas le langage (Ruby et Python étant vraiment des bons langages tous les deux).

    • [^] # Re: Python vs Ruby

      Posté par (page perso) . Évalué à 6.

      J'utilise les deux régulièrement et je te conseillerais Python si tes projets ont une taille conséquente, que tu travailles dans un domaine relativement scientifique ou si c'est ton 1er / 2e langage. Prends Ruby si tu fais principalement du développement Web ou de petits scripts qui traitent du texte.

    • [^] # Re: Python vs Ruby

      Posté par (page perso) . Évalué à 5.

      Python vs Ruby

      Je pense pareil que pour Python vs Perl : c'est le même langage, mais avec une syntaxe différente, et comme Perl : Ruby privilégie l'implicite (mais un peu moins que Perl) à l'explicite. On m'a d'ailleurs dit que Ruby On Rails repose essentiellement sur des conventions, je n'en sais pas plus :-)

      De mon expérience, un projet est vite écrit, mais devra être maintenu plusieurs années, et parfois le(s) développeur(s) initiaux quittent le projet. La priorité pour moi est la maintenance sur le long terme, et la lisibilité de Python est très importante pour moi.

      • [^] # Re: Python vs Ruby

        Posté par . Évalué à 3.

        La priorité pour moi est la maintenance sur le long terme, et la lisibilité de Python est très importante pour moi.

        Et comme dit le proverbe : on ne fait pas d'omelette sans casser un buildbot.

        (note : Victor fait beaucoup d'omelettes)

      • [^] # Re: Python vs Ruby

        Posté par . Évalué à 5.

        J'adore Python, Ruby, Javascript, Lua, Perl 5 et 6.

        Pour des raisons différentes (support, intégration, communautés, librairies/frameworks, expressivité, fonctionnalités, sûreté, performances, documentation etc).

        Je pourrais argumenter pour ou contre chacun des langages de script en fonction du contexte, de l'humeur... Je n'ai pas rafraichi mes connaissances sur Python 3 depuis un certain temps, mais je suis effaré quand je vois des assertions du genre :

        « Je pense que [Perl 6] c'est le même langage »

        « En tout cas, Perl 6 ressemble de plus en plus à Python »

        « Je pense pareil que pour Python vs Perl : c'est le même langage »

        Le tronc commun est évidemment très large. Mais deux différences de haut-niveau me viennent à l'esprit : le multiple dispatch, et les règles grammaticales.

        À quoi ça sert ? À éviter pas mal de design patterns (visiteur, interpréteur/DSL) et d'anti-patterns (sur-objectification, copier/coller). Il est très dur d'y renoncer quand on les connait (et c'est le problème). Idem pour la myriade d'opérateurs, les jonctions, les appels d'ensemble : ces fonctionnalités compliquent obligatoirement la syntaxe Perl 6, mais elles sont facultatives, c'est un pari sur l'intelligence des développeurs, leur capacité à apprendre sur le long terme. Perl 6 reste évidemment plus compliqué en mode babillage que Python 3 qui est un havre de pureté en comparaison, fait pour attirer le plus grand nombre.

        Python 3 peut donc se consoler avec la syntaxe et son vernis industriel. Mais pour profiter des mêmes fonctionnalités (qui sont parfois utiles), il doit passer par des extensions et du code surchargé avec des constructions un peu simplistes et hasardeuses (chaine littérale, décorateurs...) qui sont aussi discutables en termes de maintenance/extensibilité. Ruby contourne ça avec une analyse syntaxique plus fine et plus flexible et plus de dynamisme.

        En Perl 6, le modèle objet et les contraintes de typage sont très abouties. Ce qui peut être avantageux en termes de productivité et de sécurité. Les autres langages dynamiques exigent théoriquement d'écrire plus de tests unitaires, et de communiquer davantage par des canaux alternatifs (doc, mails, etc).

        Python est un excellent langage, opérationnellement dans la moyenne, et qui mérite d'exister. Pour l'aider à progresser, il serait plus constructif de le comparer à Ruby plutôt qu'à Perl, au nom de ses principes fondamentaux plus proches (clarté, simplicité). Il faut comparer les interpréteurs/compilateurs Python à ceux de Lua (ou de JavaScript) en termes d'implémentation et de performances. Et si on veut comparer sérieusement Python 3 à Perl 6 il faut faire attention. Sémantiquement, le combat n'est pas joué et attaquer Perl 6 sur la syntaxe, c'est un peu comme dire « l'anglais c'est mieux que le chinois », ça me paraît pas très objectif et... on en reparlera peut-être dans 10 ans ;).

        • [^] # Re: Python vs Ruby

          Posté par . Évalué à 4.

          on en reparlera peut-être dans 10 ans ;).

          Effectivement, reparlons de Perl 6 dans 10 ans :)

  • # Je vois

    Posté par . Évalué à -1.

    Comparaison ultra objectives tu veux dire :
    http://www.wikivs.com/wiki/Perl_vs_Java Finalement c'est ce qu'il y a de plus drôle chez les amoureux du Perl, leur objectivité...

    • [^] # Re: Je vois

      Posté par . Évalué à 10.

      Preuve par l'anecdote

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # Python 3 dans Arch Linux

    Posté par (page perso) . Évalué à 4.

    Pour répondre à Tarek qui dit : "Bah. Les gens qui utilisent cette distribution sont habitués à des choix exotiques non ? ;)", non les utilisateurs d'Arch ne sont pas habitués à des choix exotiques. La politique de la distribution est de respecter si possible les consignes de l'upstream et d'éviter les patchs, tout en fournissant les logiciels dans une version aussi à jour que possible.

    Le développeur responsable du changement a posté un article de blog (en anglais) suite à la sortie du PEP 394 : http://allanmcrae.com/2011/03/the-python2-pep/

    La politique officielle de la distribution est donc maintenant d'indiquer explicitement la version de python utilisée, /usr/bin/python étant réservé à un usage interactif.

  • # L'hirondelle est morte...

    Posté par (page perso) . Évalué à 10.

    Unladen Swallow est officiellement mort maintenant. Reid Kleickner, un développeur stagiaire chez Google qui travaillait sur le projet explique dans une entrée de blog les raisons de l'abandon du projet: http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html .

    En gros:

    • LLVM s'est avéré décevant pour l'optimisation de langages dynamiques. Les développeurs ont rencontré beaucoup de bugs qu'ils ont du corriger eux-même, d'où une perte de temps considérable sur le coeur du projet.

    • les projets qui sont sensibles à la performance chez Google sont finalement peu développés en Python. En dehors du module Pickle, les développeurs Google s'en sortent très bien avec le Python officiel.

    • Google est encore en Python 2.5 alors que Unladen Swallow est parti sur Python 2.6 . Du coup les projets Google ne peuvent pas bénéficier du JIT sans un effort de portage.

    • Au début de Unladen Swallow, PyPy était encore moyen en performance et ne gérait pas du tout les extensions en C ou la génération de code 64 bits, d'où un intérêt certain pour Uladen Swallow. Ce n'est plus le cas aujourd'hui.

    • Reid Kleickner a essayé de travailler sur Unladen Swallow dans le cadre de sa thèse mais on lui a dit poliment qu'il n'y avait là aucun sujet de recherche : les techniques de JIT font partie de l'état de l'art.

    Au final, ce qui reste de Unladen Swallow: - pas mal d'optimisations sur le module Pickle - quelques optimisations de ci de là dans Python - une super suite de benchmark contenant les projets majeurs en Python (twisted, django, ...) permettant d'évaluer les performance de Python sur des projets réels - une interface de débuggage pour gdb permettant de suivre le code JIT de LLVM

    La suite de benchmark de Unladen Swallow a été reprise par PyPy et sert de référence pour http://speed.pypy.org . Elle sera aussi bientôt reprise officiellement par CPython pour comparer toutes les version de Python (CPython, PyPy, Jython, IronPython, WPython, ...). Son seul inconvénient est qu'elle ne supporte que Python 2 pour l'instant (parce que les projets utilisés pour les benchmarks sont encore en Python 2).

    • [^] # Re: L'hirondelle est morte...

      Posté par . Évalué à 6.

      La suite de benchmark de Unladen Swallow a été reprise par PyPy et sert de référence pour http://speed.pypy.org . Elle sera aussi bientôt reprise officiellement par CPython pour comparer toutes les version de Python (CPython, PyPy, Jython, IronPython, WPython, ...). Son seul inconvénient est qu'elle ne supporte que Python 2 pour l'instant (parce que les projets utilisés pour les benchmarks sont encore en Python 2).

      Damned ! Non, elle est déjà disponible en Python 3 ici : http://hg.python.org/benchmarks/ (sauf pour les benchmarks applicatifs où la bibliothèque tierce n'a pas été portée)

  • # parrot

    Posté par (page perso) . Évalué à 2.

    Je trouve dommage que le langage python (ruby...) mise pas plus sur la machine parrot pour la couche basse. Parrot a été conçu pour les langages dynamiques (script) plutôt que pour le typage statique (jvm java). De plus, elle est libre et en mode de développement communautaire.

    Bref, c'est un sacré projet communautaire qui a des objectifs très ambitieux et qui pourrait, s'il était plus adopté par les autres langages de scripts que Perl6 permettre des choses formidables entre les frères ennemies ;-) Par exemple, utiliser à terme des bibliothèques de l'un ou l'autre des langages...

    Il est clair que si moins de personne l'utilise, plus il faudra de temps pour l'optimiser...

    • [^] # Re: parrot

      Posté par . Évalué à 3.

      Par exemple, utiliser à terme des bibliothèques de l'un ou l'autre des langages...

      Heu, je crois qu'il ne faut pas trop rêver. Ce n'est possible que s'il y a un modèle d'exécution sous-jacent commun (comme dans .Net). Mais les modèles objet de Python, Perl, Ruby sont différents.

      On peut toujours imaginer trouver un compromis à mi-chemin entre les différents langages, mais le résultat ne serait pas satisfaisant : cela ne semblerait "naturel" (idiomatique) dans aucun des langages.

    • [^] # Re: parrot

      Posté par (page perso) . Évalué à 5.

      Il existe le projet https://bitbucket.org/allison/pynie

      Je trouve dommage que le langage python (ruby...) mise pas plus sur la machine parrot pour la couche basse

      Quand tu écris "le langage", tu veux dire les développeurs Python ? Ou bien la fondation Python (PSF) ? La fondation Python a donné un chèque de 10.000$ à PyPy lors du dernier PyCon US (mars 2011). PyPy est déjà compatible à 100% (ou disons 99,999%) avec CPython et plus rapide que CPython sur de réelles application (dans certains cas). Il me semble plus rentable d'investir du temps et de l'argent dans PyPy que dans Parrot.

      Il existe des implémentations de Python sur la JVM (Jython) et .NET (IronPython). Mono a également pour objectif d'être la VM de tous les langages. Pourquoi Perl n'investit pas plus de temps de ressources dans Mono plutôt que de recoder (depuis zéro !) sa propre VM ?

      Il y a également eu des expérimentations avec LLVM (Unladen Swallow et une des premières implémentations du JIT de PyPy), mais les résultats étaient décevants.

      Python a beaucoup de particularités qui font que c'est un langage difficile à optimiser. PyPy semble avoir trouvé une voie qui donne des résultats concrets.

      • [^] # Re: parrot

        Posté par (page perso) . Évalué à 5.

        La JVM, .NET, ce ne sont pas des projets pilotés par la communauté... Au vu des problèmes qu'il y a eu dessus depuis leur apparition, je suis bien content que la communauté Perl essaye une autre voie. LLVM, ce n'est pas si ancien que cela et en plus, il y a Apple derrière... Par ailleurs, c'est quand même à la base fait pour faire de la compilation de langage statique.

        Pour une fois que les développeurs libres essayent de faire leur propre trucs sans chercher à suivre les autres, je trouve cela bien.

        Bref, Parrot va bien au delà du court terme, c'est un projet très ambitieux qui bénéficirait à mon sens bien plus des talents de tous.

        • [^] # Re: parrot

          Posté par (page perso) . Évalué à 5.

          Ouai, on peut dire la même chose de Hurd vs Linux. Perso, j'ai pas parié sur Hurd et je parierai pas plus sur Parrot. Etre trop ambitieux, c'est la raison no 1 d'échec des projets logiciels libres.

          • [^] # Re: parrot

            Posté par (page perso) . Évalué à 3.

            C'est pas faux.

            Le processeur qui a gagné est le x86 qui était la pire daube en 1980... Moins il y a de personne sur un projet, plus c'est dur d'avancer et de suivre les autres ;-)

        • [^] # Re: parrot

          Posté par (page perso) . Évalué à 2.

          La JVM, .NET, ce ne sont pas des projets pilotés par la communauté...

          Mono est un logiciel libre non ? Mono gère beaucoup de langages et pas que des langages statiques : http://mono-project.com/Languages

          Au vu des problèmes qu'il y a eu dessus depuis leur apparition, je suis bien content que la communauté Perl essaye une autre voie.

          À quels problèmes tu fais référence ? (je ne suis pas l'actualité des VMs)

          LLVM, ce n'est pas si ancien que cela et en plus, il y a Apple derrière...

          Tu veux dire que c'est un défaut que LLVM soit récent ? Parrot est plus ancien que LLVM ?

          Pour Apple : tant mieux qu'une société paie des développeurs pour améliorer un logiciel libre. Apple utilise LLVM pour compiler les shaders des GPU sous Mac OS X. Bah Xorg fait maintenant pareil avec Gallium. J'en comprends qu'Apple a indirectement contribué à Xorg (ou dumoins à LLVM).

          Par ailleurs, c'est quand même à la base fait pour faire de la compilation de langage statique.

          Effectivement, la JVM, .NET et LLVM sont plus à l'aise avec des langages statiques. Mais je ne suis pas sûr qu'écrire une nouvelle VM se voulant générique et adapté à tous les langages (surtout les langages dynamique) est un projet réaliste. Il faut y aller petit à petit. Parrot a été lancé depuis longtemps et il semble que l'implémentation de Perl6 (qui est liée à Parrot) ne soit pas encore terminée, et c'est le seul langage majeur supporté. En plus, j'ai entendu que les performances de Perl6 ne sont pas fameuses, le JIT ne Parrot ne semble donc pas très avancé.

          Bien sûr que Parrot est une belle idée. Bien sûr que ça serait génial d'avoir une implémentation de Python pour Parrot. Mais qui va l'implémenter ? Est-ce qu'il y a suffisamment de développeurs motivés pour aller jusqu'au bout ? Quel en est l'intérêt comparé aux autres solutions ? Perso j'attends de voir des résultats intéressants avant de m'y plonger. Pour l'instant, le seul truc que j'ai vu est que l' "assembleur" me semble assez proche du langage Perl.

          • [^] # Re: parrot

            Posté par (page perso) . Évalué à 0.

            Si tu ne sais pas que Mono a des problèmes depuis son lancement, il faut quand même se renseigner un peu ;-)

          • [^] # Re: parrot

            Posté par . Évalué à 3.

            Je suppose qu'il parle de la problématique des brevets logiciels qui portent sur Mono, ainsi que des infractions de licence que Mono aurait fait en implémentant certaines APIs non standardisées de .Net (Windows.Forms par exemple).

            • [^] # Re: parrot

              Posté par (page perso) . Évalué à 2.

              Je suppose qu'il parle de la problématique des brevets logiciels qui portent sur Mono

              C'est des questions théorique, ou ça a déjà posé des problèmes pratiques ? Est-ce que les parties qui sont soumises à des brevets font parti intégrante de Mono ou bien c'est des modules optionnels ?

              ainsi que des infractions de licence que Mono aurait fait en implémentant certaines APIs non standardisées de .Net (Windows.Forms par exemple)

              Pourquoi tu parles au conditionnel ? Ca a été implémenté ou pas ? Ca pose des problèmes de licence ou pas ?

              Effectivement, je n'ai pas du tout suivi Mono et j'en suis déjà, donc je pose des questions qui peuvent paraitre idiotes :-)

              • [^] # Re: parrot

                Posté par . Évalué à 1.

                Les risques sur Mono sont théoriques, car Microsoft n'a pour le moment pas attaqué le projet Mono.

                Est-ce que les parties qui sont soumises à des brevets font parti intégrante de Mono ou bien c'est des modules optionnels ?
                Bonne question. Je dirais que c'est optionnel, car il est recommandé d'éviter ces librairies douteuses (non couvertes par le standard ECMA) et d'utiliser les équivalents libres (GTK#, etc.), mais cela limite d'autant la portabilité.

                Si je parlais au conditionnel, c'est parce que je ne suis pas sur de me rappeler les détails :) Il me semble que cela a été implémenté, et que comme ces APIs ne sont pas couvertes par un standard, Microsoft pourrait se retourner contre Mono pour violation de propriété intellectuelle.

                Aussi, il me semble que Moonlight, la version Mono de Silverlight embarque les librairies de Microsoft pour le décodage vidéo. C'est avec l'accord de Micosoft, mais oups! ce n'est pas libre.

                Bref Mono est un projet un peu borderline, et beaucoup de contributeurs Gnome lui préfèrent Vala.

                • [^] # Re: parrot

                  Posté par . Évalué à 8.

                  Les risques sur Mono sont théoriques, car Microsoft n'a pour le moment pas attaqué le projet Mono.

                  Heu, le propre d'un risque, c'est que c'est toujours théorique. Sinon ce n'est pas un risque, c'est une certitude.
                  (en d'autres termes, ta phrase, c'est un peu du FUD à l'envers)

                  • [^] # Re: parrot

                    Posté par . Évalué à 1.

                    S'pa faux! Je répondais juste a la question de Victor :)

                • [^] # Re: parrot

                  Posté par (page perso) . Évalué à 2.

                  Aussi, il me semble que Moonlight, la version Mono de Silverlight embarque les librairies de Microsoft pour le décodage vidéo. C'est avec l'accord de Micosoft, mais oups! ce n'est pas libre.

                  Mais euh, Moonlight et Mono sont dans le même dépôt source ? Est-il possible d'utiliser Mono sans installer / utiliser Moonlight ?

                  Même questions pour les autres trucs "borderline" (comme tu dis) comme Windows.Forms.

                  Je ne vois pas en quoi c'est un soucis pour Mono que des gens l'utilisent pour coder des trucs non libres. Je pense qu'il y a plein de logiciels libres qui tournent sur des VM non libres... et inversement ;-)

                  (Il parait même que des gens développent des applications Python non libres alors que Python est libre, rooooh !)

                  • [^] # Re: parrot

                    Posté par . Évalué à 1.

                    Mais euh, Moonlight et Mono sont dans le même dépôt source ? Est-il possible d'utiliser Mono sans installer / utiliser Moonlight ?

                    Très certainement. C'est juste pour souligner que tout ce qui est abrité sous l'aile de Mono ne sent pas bon et comporte des risques. C'est alors a l'utilisateur de faire son choix e connaissance de cause. Python est beaucoup plus simple a utiliser et clair de ce cote la.

                    Même questions pour les autres trucs "borderline" (comme tu dis) comme Windows.Forms.

                    C'est ce que je dis: le projet Mono encourage a utiliser GTK# au lieu de Windows.Forms. Mais parce que ce dernier est disponible, un zozo va inévitablement l'utiliser sans se poser de questions outre mesure, et ceci, même pour un projet libre. Maintenant, a mon avis Mono a décidé de supporter ces APIs windows only pour donner de la portabilité aux programmes les utilisant sous Windows. Microsoft s'en moque car Mono a souvent plusieurs trains de retard, Microsoft reste la référence pour .Net et l'on n'a pas vu de migration massives de .Net+Windows vers Mono+plateforme libre.

                    (Il parait même que des gens développent des applications Python non libres alors que Python est libre, rooooh !)

                    Oui et ils ont raison d'utiliser une plateforme libre, sans risque connu de brevets logiciels.
                    Même si ce serait mieux qu'ils fassent du logiciel libre sur une plateforme libre :P

  • # Quel éditeur ?

    Posté par . Évalué à 3.

    Je viens me m'apercevoir que personne n'avait posé la question trollesque: quel est votre éditeur de prédilection pour le dév. Python ?

    • [^] # Re: Quel éditeur ?

      Posté par (page perso) . Évalué à 4.

      La question revient tous les 3 mois sur comp.lang.python . On est VendredI Mais je ne VaIs Même pas rentrer dans le troll. Ou alors inVIsibleMent...

      Plus sérieusement, au delà de l'éditeur, je cherche régulièrement un bon débogueur graphique pas à pas. Pdb, c'est gentil mais perso, je préfère le confort visuel.

      J'ai utilisé Eclipse + pydev un temps, mais quand on développe pas sous Eclipse, c'est un vraiment lourd. Et régulièrement, il me sautait allègrement mes points d'arrêts, il ne prenait pas ma version de Python par défaut, et autres joyeusetés. Komodo est pas mal mais c'est payant et quand même un poil lourd. Maintenant, je me suis rabattu sur winpdb . C'est encore un peu rustique (supporter le drag'n drop pour ouvrir des fichiers par exemple, ce serait sympa) mais au moins, ça débugge correctement.

      • [^] # Re: Quel éditeur ?

        Posté par (page perso) . Évalué à 3.

        J'utilise vim. Pour le code C, ^] (avec ctags) est pratique pour aller à la définition d'une fonction. Pour le code Python, j'aimerai bien savoir comment aller au début/à la fin d'une fonction/classe Python, mais je me débrouille autrement (je cherche "def " et "^class "). Pendant une dizaine d'année, j'ai développé sans la complétion. Maintenant j'en abuse, ça évite les fautes de typo à la con.

      • [^] # Re: Quel éditeur ?

        Posté par (page perso) . Évalué à 3.

        Utilise pudb, c'est en console mais ça utilise urwid, et c'est assez agréable pour le débug: http://pypi.python.org/pypi/pudb .

    • [^] # Re: Quel éditeur ?

      Posté par . Évalué à 2.

      J'utilise Scite, wscite en particulier. Simple et efficace et wxdesigner.

    • [^] # Re: Quel éditeur ?

      Posté par . Évalué à 5.

      J'utilise Kate, qui n'apporte rien de spécial pour Python mais est très bon en soi :)

  • # Youpi

    Posté par (page perso) . Évalué à 2.

    Longue vie à l'opérateur % !

Suivre le flux des commentaires

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