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: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 chose dans 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 celà 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 coeur 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 ténté 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 utilison 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 puissons commencer à porter certains de ces outils vers Python 3 pour Fedora 14.
Quels ont été les développements pour rendre celà possible ?
Il a fallu adapter RPM pour supporter plusieurs environnements Python, j'ai ajouté quelques tests à l'outil "rpmlint" pour celà. 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. Celà 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 ?"
https://fedoraproject.org/wiki/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 monitoring. 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 pouvé 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 particuliers. Donc tu peux écrire des scripts qui vont surveillers 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 utiliser ceci pour faire du profilage, et déterminer quels 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 aavaut 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.
I'm still trying to figure out how a Normal Python Programmer would get started with this coolness.
I think a pair of screencasts is the way to go, showing rather than telling.
Ok - we'll make a note to make those screencasts. (Ed. note: watch for more Python on Fedora 13 material coming out soon!) On to debugging?
Yay!
Tell us about "Easier Python Debugging." What does that mean?
One of the great things about Python is how easy it is to wrap external libraries (e.g. written in C).
What this means is that if you have some code that's written in another language - C is a common example - that you want to interface with in the Python code you're writing - Python makes it easy to do that. You can have your C code and your Python code "talk" to each other by writing a little bit of Python code to go around the C.
The downside of this is that if one of these libraries has a bug, then that bug takes out the whole of the Python process, without giving you a nice Exception/traceback.
I found an example of a... not-nice Exception/traceback from when this kind of thing happens.
Since we added the ABRT tool, I see a lot of Python crashes - which typically aren't crashes in Python itself, they're crashes in the libraries. I've spent a lot of time debugging these things, and I wanted to make my life easier.
For example, in Fedora 12 (I believe), we shipped GTK-2.18, which contained Alex Larsson's bug rewrite of how GTK writes stuff to the screen, greatly reducing on-screen flicker. But the downside is that a few applications broke. An example turned out to be the "istanbul" screencast-recording tool; figuring that out was "fun."
Python has long had a set of macros - small libraries - for gdb, the gnu debugger, that let you connect to a running (or dying) python process and debug what's going on, but they're fiddly to use and they assume the process is only "lightly broken." For example, they add a "pyo" command, for printing python objects. In theory, it's equivalent to "print" in Python on that object, but if the object is internally corrupt, if you run it, you'll merely get another crash.
The other big problem is that the macros really assume you're proficient with gdb and know your way around the insides of Python. So I started looking for a better way of doing this.
In Fedora 12 (I believe), Fedora gained a shiny new version of gdb. Various people worked on improving C++ debugging, but one of the by-products of that was that gdb 7 now has the ability to be extended using Python. A bunch of Red Hatters added this; it's now possible to write Python code that hooks into the debugger, to pretty-print data types.
What I did was use this to write Python code that knows about the insides of Python itself, so you now have Python code running inside the gdb process, which knows how to scrape data out of another dying process. The practical upshot is that it's now possible to attach to an already-running Python process with gdb and type:
py-list
...which will show you the python source code that's currently running,
py-bt
...which will show you a Python-level backtrace,
py-up
...which will take you up the call stack, and
py-down
...which will take you down the call stack. And when you print data, it will tell you what the data is, in a meaningful way. So rather than being told the hexadecimal address of where the object is stored in RAM, gdb should tell you that e.g. you have a [1, 2, 3]. Plus, now if ABRT, the Automatic Bug Reporting Tool, detects a crash of a python process, the report should automatically the file/line information at the Python level and the values of all of the Python vars, rather than just hexadecimal noise.
Sounds like another getting-started screencast we should make.
The caveat is that it works well on i686, but less well on x86_64; it ought to work on Python 3, but I think there are some bugs there. I've set it up so that if you install python-debuginfo, it should all Just Work. I think I still have some testing to do on Python 3 for this, so I'd recommend trying it out on python 2, with i686.
Please file bug reports against "python" and "python3" as appropriate - this stuff lives in the -debuginfo subpackages of those src.rpms. If you see a Python traceback inside gdb, then that's likely a bug in my code; please file a bug if you do see this. The code tries to be robust in the face of arbitrary breakage of the process being debugged - we are trying to debug crashes, after all!
Bien, cette fonctionnalité étant développé à 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 esssayé 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 intransigent 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 !