The Fedora Marketing team built this interview as part of their work promoting the latest and greatest free and open source software technologies that Fedora brings with each new release. If you're interested in participating in Fedora, visit http://join.fedoraproject.org to get started.
Éclairage sur...
Les développeurs Python seront particulièrement intéressés par la dernière Fedora 13 avec les fonctionnalités débogage Python facilité et environnement Python 3 installable en parallèle, plus prise en charge de Python par SystemTap. Nous vous présentons une interview de David Malcolm, un des développeurs responsables de ces fonctionnalités.
Une interview vidéo de David Malcom est disponible via le blog presse de Red Hat.
Interview avec David Malcolm
Parle nous de toi, d'abord.
Salut, je suis David Malcolm. Je m'intéresse à Linux depuis 10 ans environ, j'ai travaillé sur différentes choses au sein de la communauté GNOME. Je travaille pour Red Hat, et je suis assez chanceux pour être payé pour faire du logiciel libre (youpi!). J'ai appris le langage Python il y a quelques années et celui-ci est devenu très rapidement mon langage de programmation favori. Red Hat me paie pour rendre Python encore meilleur.
Qu'est-ce qui te plait à propos de Python ?
Il correspond très bien à ma façon de programmer : ce qui doit être simple à faire l'est, mais il est capable de réaliser les tâches complexes sans introduire de complexité inutile. Ainsi, je peux écrire un script simple pour les tâches quotidiennes, mais potentiellement développer quelque chose de plus construit.
Fedora 13 comporte trois fonctionnalités reliés à Python, commençons par l'environnement Python 3 installable en parallèle. Qu'est-ce ? Et en quoi c'est utile ?
Python 3 corrige des problèmes inhérents au langage, mais cela implique que beaucoup de choses changent entre Python 2 et Python 3. En un certain sens, vous pouvez les considérer comme différents langages.
Quand nous parlons d'un environnement Python, celui-ci repose sur trois composants: l'"interpréteur" au cœur de celui-ci, la "bibliothèque standard", et une collection de modules tiers par dessus. La bibliothèque standard est souvent décrite comme étant "piles incluses" car très riche, mais malgré cela, le besoin de modules tiers existe. Il existe des centaines, si ce n'est des milliers de modules, certains ayant besoin d'autres modules, et la plupart envisage de passer à Python 3.
Donc beaucoup de développeurs Python devront faire face à la décision de passer à Python 3 - "Est-ce que l'environnement Python 2 ou Python 3 me fournit les modules dont j'ai besoin ?"
Python fournit un outil nommé "2to3" capable convertir automatique une bonne partie du code Python 2 en code Python 3,à condition de respecter certaines règles. Malheureusement, il n'est pas très clair quels sont les modules qui ont été portés et ceux qui ont besoins de l'être. Certains nouveaux modules sont directement écrit pour Python 3, d'autres modules pré-existants le supporte déjà, d'autres encore viennent juste de commencer le portage.
Et la réponse de Fedora est "Bon, on aura les deux."
Dans Fedora 13, nous fournirons deux environnements Python, un environnement Python 2 et un environnement Python 3.
Et vous pouvez utilisez simultanément Python 2 et Python 3 - pas besoin de choisir l'un ou l'autre.
Je ne suis pas certain de combien de paquets nous avons pour Python 2 dans Fedora, mais il y en a beaucoup.
Une note à l'attention de nos lecteurs développeurs Python - Python 2 est l'actuel environnement Python dans Fedora, donc si vous avez développé et fait tourné du code Python dans Fedora, vous utilisez Python 2.
Pour l'environnement Python 3, nous avons tenté de fournir les paquets RPM python connu pour fonctionner avec Python 3. Une des approches que nous aurions pu suivre aurait été de passer la moulinette "2to3" sur tout les paquets, mais sans aucune garantie sur le résultat final.
Donc le fonctionnement de ces paquets avec Python 3 dans F13 a été testé ?
Oui. Si vous voyez un RPM "python3-foo" dans Fedora 13, vous êtes certain qu'il est fonctionnel. On ne s'est pas contenté de tout balancer sur le mur, nous avons inspecté plusieurs modules, choisis ceux connus pour fonctionner puis tester ceux-ci.
Et nous l'avons fait en partie parce que nous même avons besoin de Python 3.
Nous utilisons Python 2 un peu partout dans Fedora. Une large partie de l'infrastructure web de Fedora est écrite en python, ainsi que les outils système comme l'outil de mise à jour ("yum"), l'installeur ("anaconda"), et une multitude d'outils de configurations graphiques ("system-config-*"). J'ai bon espoir que nous puissions commencer à porter certains de ces outils vers Python 3 pour Fedora 14.
Quels ont été les développements pour rendre cela possible ?
Il a fallu adapter RPM pour supporter plusieurs environnements Python, j'ai ajouté quelques tests à l'outil "rpmlint" pour cela. J'ai aidé à porter les bindings Python afin de prendre en charge Python 3 (inclus dans rpm-4.8.0).
J'ai entre autre écrit un outil aidant les personnes à porter leurs extensions C. Une chose sympathique à propos de Python est qu'il est très facile d'écrire du code glue entre Python et C, et il y a pas mal de code dans les parages. Malheureusement, le passage de Python 2 et Python 3 nécessite quelque modifications. J'ai rencontré cet écueil lors du portage des bindings Python de RPM. La moitié du travail demande réflexion, l'autre partie va de soi, une fois que vous avez compris.
J'ai donc écrit un outil pour automatiser les tâches qui peuvent l'être que j'ai baptisé 2to3c, en hommage à l'outil 2to3. John Palmieri l'a utilisé pour le port des bindings Python de DBus.
Sympa. Je vois les instructions de téléchargement et d'utilisations, ça me semble être un projet jeune qui a besoin d'aide, de testeurs et de retours.
Tout à fait, c'est encore expérimental pour le moment. Tout aide est la bienvenue !
Ainsi, nous aurons un excellent environnement Python 3 platform dans Fedora 13 : Je crois que nous avons un environnement Python 3 aux petits oignons, avec une sélection pertinente d'extensions disponibles via RPM. Cela devrait être utile aux personnes voulant porter leur code ou bien apprendre le langage. Python 3 est bien plus simple d'apprentissage que Python 2, la plupart des complexités inutiles ont été supprimés.
Quel est le meilleur point de départ pour ceux qui se disent "Sympa, par où je commence ?"
Features/Python3F13#How_To_Test. Bien que je pense qu'on puisse améliorer ce paragraphe.
Nous allons retenir ce point et avancer. Si quelqu'un veut nous aider avec notre documentation sur Python 3, qu'il ne se gène pas pour éditer la page ! david, un dernier commentaire sur les environnements parallèles ?
C'était une demande récurrente. Il y a déjà eu plusieurs propositions à ce sujet sur la liste de diffusion.
Le plus important était d'assurer l'indépendance vis à vis de l'environnement Python 2 afin de ne pas casser celui-ci. "Ne traverser pas les flux !' (NdT: citation du Dr Egon Spengler - GhostBuster) (à quoi ça ressemble ?)
Tu viens de faire une référence à [1]. Nous avons tout bon. Passons aux sondes SystemTap ! Eh bien ... j'ai fait un peu de développement Python moi-même mais suite à la la lecture de cette feature description, je suis un peu confus. Ça parle quoi ?
Eh bien Systemtap est un outil de traçage, sondage et de surveillance. L'idée est (alerte métaphore !) est que tu places des sondes sous le capot de ta machine et que tu regardes ce qui se passe. Par le passé, les seuls endroits que l'ont pouvait sonder étant dans le noyau. Pour Fedora 13, j'ai rajouté des sondes dans les interpréteurs Python 2 et Python 3 pour surveiller les appels de fonctions Python en particulier. Donc tu peux écrire des scripts qui vont surveiller les appels à un module spécifique ou bien à une fonction Python donnée dans tout le système ou pour un processus.
Peux-tu nous donner quelques exemples ?
Comme exemples, j'ai fourni quelques scripts. J'ai écrit un outil type "top" qui surveille chaque appel Python par seconde dans le système et un autre vous montre les appels Python et la hiérarchie attenantes. Ceux-ci peuvent être utiles tels quels et chacun peut écrire ses propres fonctions à l'aide du langage de domaine spécifique de SystemTap.
Quels sont développeurs Python qui sont directement intéressés par ceux-ci ? Y-a-t'il des projets qui seraient plus intéressés que d'autres ?
J'ai montré mes scripts à Paul Frields (Ed. note: Paul commence à développer en Python depuis peu) en utilisant un programme qu'il a écrit, et ses yeux se sont écarquillés. C'est un excellent outil pédagogique : vous pouvez voir ce que fait votre code, directement.
Donc c'est quelque chose utile pour les novices en programmation.
Un autre cas d'utilisation : un site web écrit en Python peut s'en servir pour faire du profilage, et déterminer quelles sont les parties les plus utilisées.
Y-a-t'il d'autres détails techniques à connaitre ?
Je devrais mentionner les travaux de Sun et d'Apple surDTrace, qui sont proches de SystemTap. Il y avait quelques patchs pour ajouter la prise en charge de Python qui se baladaient depuis un certain temps pour DTrace, Mark Wielaard a ajouté un bout de compatibilité DTrace dans Systemtap. Ainsi, on semble faire tourner DTrace (durant la compilation de Python), mais en fait, tout se faut dans Systemtap.
J'essaie d'imaginer comment un développeur Python pourrait s'initier à cette fantastique technologie.
Je pense que quelques screencasts devraient faire l'affaire, montrer plutôt que de raconter.
Ok, je note de faire quelques screencasts. Sur le débogage ?
Youpi !
Parle-nous un peu du "débogage Python facilité." Qu'est-ce que ça veut dire ?
Un des aspects sympathiques de Python est la facilité avec laquelle, on peut encapsuler des bibliothèques externes (par exemple, écrites en C).
Cela signifie que si tu as du code écrit dans un autre langage (C étant un exemple commun), et que tu veuilles l'interface avec du code Python, Python te facilite la tâche. Tu peux avoir ton code C et ton code Python "dialoguer" à l'aide d'un peu de code Python autour du C.
L'aspect négatif de ceux-ci et que si une de ses bibliothèques a un bogue, ce bogue affecte tout le processus Python sans te fournir l'exception et/ou la traceback qui va bien.
J'ai trouvé un exemple d'une traceback assez rebutante ... quand ce genre de choses arrivent.
Depuis que j'ai rajouté l'outil ABRT, Je vois une tonne de crashs Python qui habituellement, ne sont des bogues Python en soi, mais des bibliothèques. J'ai passé pour beaucoup de temps à déboguer ce genre de choses et j'ai voulu me simplifier la vie.
Par exemple, dans Fedora 12 (si je ne m'abuse), nous fournissons GTK-2.18, contenant le correctif d'Alex Larsson réécrivant la gestion du buffer d'affichage de GTK réduisant grandement les artefacts. Mais la contrepartie est que cela cassait quelques applications. Par exemple, pour l'outil de capture vidéo d'écran "istanbul", ce fut "amusant" de dénicher où se situait le problème.
Python a depuis longtemps un jeu de macros (quelques bibliothèques annexes) pour le débogueur GNU gdb, qui permettent de se connecter à un processus Python en cours (ou mourrant) et le déboguer, mais ils sont délicats à utiliser et partent du principe que le processus est "légérement abimé". Par exemple, ils ajoutent une commande "pyo" pour imprimer les objets Python. Théoriquement, c'est l'équivalent d'un "print" en Python sur l'objet, mais si celui-ci est corrompu, vous n'aurez qu'un autre crash de plus.
L'autre gros problème est que ces macros considèrent que vous êtes familier avec gdb et les entrailles de Python. Donc j'ai commencé à chercher une meilleure façon de faire.
Dans Fedora 12 (je crois), Fedora gagne une version hautement améliorée de gdb. De nombreuses personnes ont travaillés à améliorer le débogage C++, mais l'une des conséquence est que gdb 7 gagne la possibilité d'être étendu à l'aide de Python. Un groupe de Red Hat a permis ceci, désormais, on peut écrire du code Python capable de s'interfacer avec le débogueur et d'avoir un affichage plus jolie des types de données.
Ce que j'ai fait, c'est d'écrire du code Python ayant connaissance avec les entrailles de celui-ci même, donc vous avez désormais du code Python exécuté dans le processus gdb qui lui sait comment soutirer les informations d'un autre processus malade. L'aspect pratique immédiat est qu'il est possible maintenant d'attacher un processus Python en cours dans gdb et de taper :
py-list
...ce qui vous affichera le code source du processus Python en cours d'exécution,
py-bt
...ce qui vous affichera les backtraces Python
py-up
...ce qui vous aménera la pile d'appel, et
py-down
...ce qui vous fera parcourir cette même pile d'appel. Et quand vous afficherez les données, il vous dira quels sont les données de manière utile. Donc au lieu de se voir jeter au visage, l'adresse hexadécimale où est stocké l'objet en mémoire, gdb devrait vous dire par exemple que vous avez [1, 2, 3]. De plus lorsque ABRT (Outil Automatique de Rapport de Bogues) détecte le crash d'un processus Python, le rapport comporte les informations au niveau de Python, la valeur de toutes les variables Python plutôt le bruit hexadécimal habituel.
On dirait qu'un autre screencast de présentation se profile à l'horizon.
Le point noir est que tout ceci marche parfaitement sur i686 mais moins bien sur x86_64. Ça devrait fonctionner avec Python 3 mais je suppute l'existence de quelques bogues. J'ai fait en sorte que si tu installes python-debuginfo, tout doit fonctionner tout simplement. Je pense avoir quelques tests à faire avec Python 3 donc je recommande d'essayer avec Python 2 sur i686.
S'il vous plait, rapportez les bogues pour "python" et "python3", ces choses là vivent dans les sous-paquets -debuginfo de ces src.rpm. Si vous voyez un traceback Python dans gdb, c'est probablement un bogue dans mon bogue, idem, rapportez-le. Le code tente d'être robuste face aux arrêts arbitraires du process débogué, après tout, nous essayons de déboguer des crash !
Bien, cette fonctionnalité étant développée à l'origine pour Fedora, est-elle la première distribution à la fournir ?
Oui. J'ai récemment proposé ce code en amont, dans le dépôt SVN de Python, et ce sera probablement dans Python 2.7 à sa sortie, bien que cela fonctionne parfaitement avec la 2.6.
En d'autres termes, la communauté Python a apprécié ton travail et a décidé de l'incorporer au langage Python lui-même. C'est un très bel exemple de la capacité de Fedora à innover puis à en faire profiter l'écosystème du logiciel libre en le poussant en amont.
Je crois que Debian et Ubuntu ont une version de mon correctif, bien que je crois que leur version de gdb ne comporte pas tous les correctifs nécessaires pour prendre en charge l'ensemble des commandes d'extensions (bien que le prettyprinting doive marcher chez eux).
Je suppose que tester et faire des retours est la chose la plus utile que l'on puisse faire pour cette fonctionnalité.
Oui. Testez la s'il vous plait. J'ai essayé de la rendre la plus robuste possible, mais il existe plusieurs façons surprenantes pour faire échouer un programme ou des bibliothèques complexes. Donc si vous voyez des tracebacks Python dans gdb, je vous prie de rapporter les bogues. Et vos suggestions pour faciliter le débogage Python sont les bienvenues. Dans Fedora 14, j'aimerais aller plus loin comme par exemple, ajouter des points d'arrêts au niveau de Python dans gdb.
Un bon point pour cette fonctionnalité, c'est que bien que "bas niveau", le code est écrit en Python, donc un développeur Python avec une idée d'amélioration peut directement le faire. J'ai un intérêt très poussé, si ce n'est intransigeant de faciliter le débogage Python !
Merci, David. Par ailleurs, que fais-tu quand tu ne programmes pas ?
Je passe le temps avec ma femme et mon chat, dans notre jardin.
Ça semble être une manière agréable de passer le temps.
Sauf quand il pleut !
Merci d'avoir pris le temps de nous répondre, David !
Merci !