Interview de Guido van Rossum (Python)

Posté par (page perso) . Modéré par Xavier Antoviaque.
Tags :
0
12
mar.
2003
Python
Après quelques semaines d'attente, voici l'interview promise de Guido van Rossum, le concepteur du langage Python. Guido ne parlant pas le français, elle s'est déroulée en anglais, mais une traduction française vous est proposée.

Vous pouviez proposer vos questions lors d'une dépêche précédente. J'ai essayé d'en reprendre la quasi-totalité, exception faite de celles qui avaient déjà été posées à l'occasion de précédentes interviews. Si la vôtre n'apparaît pas dans l'article, référez-vous au lien ci-dessous, j'ai placé des URLs en réponse à celles qui ont ainsi été éliminées. [English speakers, the English version is a few lines below.]


Da Linux French Page: Bonjour, Guido. Je suis heureux de te rencontrer, même si ce n'est qu'électroniquement. Les questions qui vont suivre proviennent en partie des utilisateurs de linuxfr.org, et en partie de moi.

Premièrement, qu'aimerais-tu dire aux personnes n'utilisant pas Python, afin qu'ils l'essaient - et accessoirement qu'ils continuent à lire cet interview ? En posant cette question, je pense plus particulièrement aux personnes qui ont déjà un peu entendu parler de Python, mais qui n'ont pas eu le courage d'essayer un autre langage.


Guido van Rossum: Je dirais « toute résistance est futile -- vous serez assimilés. » :-)

Sérieusement, il existe de nombreuses raisons qui peuvent empêcher d'essayer Python, et pour chacune il suffirait d'une petite poussée dans la bonne direction pour que l'envie de jetter un coup d'oeil l'emporte. Que vous programmiez actuellement en C, C++, Java ou Perl, Python possède certains avantages dont vous devriez au moins connaître l'existence : la clarté de l'expression, la lisibilité, la facilité de maintenance, le tout dans un paquetage ouvert incluant une large bibliothèque standard, et un nombre de logiciels libres tiers encore plus important.


DLFP: Une des choses que j'aime dans Python est sa documentation claire, complète et dans laquelle il est facile de se retrouver (http://www.python.org/doc/current/), ainsi que la possibilité de créer la documentation des interfaces depuis le code source. De bonnes choses arrivent de ce côté, avec le développement de docutils (http://docutils.sourceforge.net/) et de reStructuredText (http://docutils.sourceforge.net/rst.html). Quels sont selon toi les bénéfices d'une telle approche ?

Guido: Si souhaité, il est possible de générer une documentation de référence pour un projet à partir de ses doc strings (chaînes de documentation). docutils et reST sont les meilleurs outils disponibles pour produire une documentation lisible à partir des doc strings.


DLFP: Que penses-tu de la programmation litérale (http://www.literateprogramming.com/) ? Et de la programmation via un éditeur de profils (comme leo par exemple - http://personalpages.tds.net/~edream/front.html) ?

Guido: J'aime l'idée de la programmation litérale, mais je ne l'ai pas essayée personnellement. Il me semble que la programmation litérale est surtout utile lorsque l'on projette d'écrire de la documentation expliquant le fonctionnement du code, que ce soit dans le cadre d'un tutoriel ou en l'écrivant de manière à ce qu'il puisse être maintenu par des développeurs moins qualifiés. J'ai parcouru des projets utilisant la programmation litérale, et j'ai souvent éprouvé de l'impatience en lisant les parties qui n'étaient pas du code. :-)

Ceci dit, je trouve le projet Leo extrêmement estimable pour d'autres raisons.


DLFP: Quelles sont-elles ?

Guido: L'aspect intéressant (pour moi) de Leo est que son auteur a essayé une variété de langages différents pour implémenter son système (plus d'une dizaine), puis a décidé de tout réécrire en Python.


DLFP: Tu as dit il y a quelque temps qu'une part de la communauté Python était effrayée de voir le langage évoluer trop vite. Personnellement, cela m'importe peu tant que chaque branche est supportée et que Python conserve une compatibilité ascendante entre les versions majeures. Je suis même relativement excité chaque fois qu'une nouvelle version sort, car elle ajoute souvent de nombreux éléments utiles au langage. Comment est-ce que ce besoin de « ralentir » modifie la manière de développer Python ?

Guido: Supporter d'anciennes versions nous coûte de nombreux efforts. Alors que nous travaillons sur Python 2.3, nous maintenons toujours Python 2.2 (la 2.2.2 venait tout juste de sortir et nous prévoyons déjà la 2.2.3), et même Python 2.1 (nous pourrions sortir la 2.1.4 dans le futur pour résoudre un problème de sécurité). L'effort revêt plusieurs formes : nous devons décider quels correctifs de la version actuelle sont suffisament importants pour nécessiter un port sur d'anciennes versions; étant donné le nombre de correctifs apportés à la version courante, ce n'est pas une tâche aisée, et si ce n'est pas fait directement il est simple d'oublier. Ensuite il y a l'effort du port proprement dit. Avec de la chance, c'est un patch sur un fichier qui s'applique correctement sur l'ancienne version. Mais au fur et à mesure que la version courante voit son code nettoyé, restructuré et ainsi de suite, les chances de voir s'appliquer proprement le patch diminuent, et il y a alors un véritable effort à fournir. De plus, pour être consciencieux, il est également nécessaire de porter un test unitaire (unit test) pour le correctif. Et il y a alors le coût de sortir une nouvelle version. En additionnant tout (le marquage CVS, la génération d'une archive, de l'HTML, d'un installateur Windows, la mise à jour du site web, l'envoi des annonces) cela prend en général quelques jours de travail. (Lire les PEP 101 et 102 pour voir le soin que nous apportons à la préparation de nouvelles versions.)

Maintenir la compatibilité ascendante coûte également, même si nous ne maintenions pas d'anciennes versions : la compatibilité ascendante stricte rend impossible l'ajout au langage de nouveaux mots réservés, et réduit donc sévèrement les possibilités de nouvelle syntaxe. De même, je dois admettre que certaines vieilles fonctionnalités n'ont pas été aussi bien implémentées qu'elles auraient pu l'être, mais l'obligation de compatibilité ascendante rend difficile leur correction. Nous trouvons en général un moyen d'y parvenir, mais pas sans coûts (par exemple, il peut être nécessaire d'ajouter une sorte d'incantation magique à chaque module qui utilise une nouvelle fonctionnalité). Cependant, j'accorde beaucoup d'importance à la compatibilité ascendante, car c'est la seule manière de continuer à agrandir la communauté des utilisateurs de Python tout en permettant à chacun de migrer vers une nouvelle version lorsqu'il est prêt.


DLFP: Considères-tu comme possible l'intégration de wxPython (http://www.wxpython.org/) dans la librairie standard ? Il possède de nombreuses fonctionnalités supplémentaires par rapport à Tkinter. [Patrice Vetsel]

Guido: Non; à cause des différences au niveau des cycles de développement entre wxPython et le coeur de Python, je pense qu'il est préférable que wxPython reste un projet parallèle. Ceci dit, je suis d'accord sur le fait qu'il possède plus de fonctionnalités que Tkinter, et j'encourage les gens à l'essayer. Il n'y a vraiment aucune raison de se restreindre aux modules inclus dans la distribution standard !


DLFP: Penses-tu que des projets tel que (http://psyco.sourceforge.net/), qui cherchent à accélérer la vitesse d'exécution, sont réellement utiles ? Seront-ils un jour inclus dans la distribution standard ? [Etienne Labaume, Patrice Vetsel]

Guido: Je pense que ce ne sera pas avant quelques années, mais je trouve Psyco très prometteur et je crois qu'il va changer notre manière de réfléchir aux performances des programmes en Python.


DLFP: Que penses-tu du projet Parrot (http://www.parrotcode.org/), dont l'objectif est de développer une machine virtuelle commune aux langages interprétés, tels que Perl 6, Python, Ruby et Perl ? [Jean-michel Fayard]

Guido: Je leur souhaite bonne chance, mais je ne pense pas qu'ils réussiront. Ils sous-estiment grandement les efforts qui sont placés dans le développement d'une machine virtuelle pour chaque langage de programmation. Même des langages aussi similaires que Ruby et Python ont des astractions de fonctionnement fondamentallement différentes, et la différence entre Python et Perl est encore plus importante. (Par exemple, les concepts de chaînes de caractères et de nombres sont totalement différents dans ces deux langages : en Python, ce sont des types différents et immutables, alors qu'en Perl ils sont du même type et mutables.) Je m'attend à ce que Parrot fasse très bien fonctionner Perl 6, mais très mal les autres langages. Bien entendu, je serais heureux d'avoir tort (exception faite du bref moment où je recevrai une tarte à l'OSCON 2004), mais je ne m'attends pas à ce que cela arrive.


DLFP: Pourquoi, à ton avis, Python est-il moins populaire que d'autres langages tels que Perl, PHP ou Java ? Ca ne semble pourtant pas être un problème de manque de fonctionnalités... [bricabrac]

Guido: Python est toujours moins populaire que Perl ? :-)

Sérieusement, il y a différentes raisons pour chacun : Perl était là le premier, et Python le rattrape; PHP est entièrement focalisé sur le développement web simple, qui est actuellement très populaire (mais au fur et à mesure que les sites grossissent, ils tendent à passer de PHP à Zope afin de rester gérables); Java est accompagné d'une énorme machine marketing.


DLFP: Peux-tu nous en dire plus à propos des divers avantages que les frameworks Web Python ont à offrir aux webmasters, en comparaison par exemple avec PHP ou Perl ? Y a-t-il des désavantages ?

Guido: Désolé, ce n'est pas mon domaine de prédilection. tout ce que je connais est la vue d'ensemble qui me permet d'affirmer que l'utilisation de Python peut mener à un code plus facilement gérable. Il est apparemment très simple de débuter en PHP, puis de finir avec un embroglio de code spaghetti.


DLFP: Que penses-tu de C# ? de .NET ? [maxoub]

Guido: Techniquement, ce sont de bons concepts, mais il est inadapté de les juger sur leurs mérites techniques; Microsoft les utilise pour conserver sa domination du marché. Bien que certaines parties sont redéveloppées en logiciels libres, je m'attends à ce que Microsoft essaie d'utiliser les brevets logiciels pour empêcher que certaines parties essentielles soient réimplémentées, afin qu'ils puissent clamer que leur version est d'une qualité supérieure.


DLFP: Existe-t-il des projets communs à Python et .GNU (DotGNU - http://www.dotgnu.org/) ? [Etienne Juliot]

Guido: Je ne sais pas. Je n'avais jamais entendu parler de .GNU jusqu'à ce que tu le mentionnes.


DLFP: Quelle est ton opinion à propos de Stackless Python (http://www.stackless.com), utilisé par exemple par Eve Online, un Jeu de Role Massivement Multijoueur (http://www.eve-online.com/faq/faq_08.asp) ? [Sidoine de Wispelaere]

Guido: Stackless est un hack fascinant. Sous sa forme actuelle, il ne satisfait pas les critères d'inclusion dans le coeur de Python; je suis donc heureux que Christian Tismer ait accepté de le conserver en tant que projet séparé.


DLFP: J'essaye de me servir de Python pour apprendre à scripter simplement à des non-informaticiens (et qui n'ont pas l'ambition d'en devenir). D'autres programmes (Blender, PaintShopPro, Gnumeric) l'utilisent pour la meme chose : l'écriture de macros. Une limite que je rencontre est la langue : tout le monde n'est pas anglophone, et une partie de la facilité de lecture de Python est perdue pour les non-anglophones. Est-il possible, à ton sens, d'introduire des versions traduites du langage ? [jm]

Guido: Pour ce que je sais, la seule version traduite de Python de la manière que tu décris existe en Chine, où quelqu'un entretient une version permettant de remplacer les mots-clés par des mots en chinois.

En général, je ne suis pas en faveur de cette pratique, et je doute que cela fasse une grande différence à l'âge d'Internet. Il peut être possible de traduire la syntaxe du coeur et quelques bibliothèques clé, mais à un moment ou à un autre il sera nécessaire d'apprendre également les mots anglais. D'après mon expérience, les concepts de programmation sous-jacents constituent la partie vraiment délicate, et non les mots utilisés pour les exprimer. Et bien que tu puisses ne pas le réaliser, les anglophones ont également des problèmes pour se souvenir des mots !


DLFP: Y a-t-il des projets pour introduire des fonctionnalités de programmation orientée aspect à Python (http://aosd.net/) ? [Jiba]

Guido: Aucune dont je sois au courant. Si tu es intéressé par ce travail, tu peux probablement en réaliser la majorité via l'utilisation des metaclasses et des héritages mutiples, ceci dit.


DLFP: Si tu commençais le développement de Python aujourd'hui, à quoi ressemblerait-il ? Serait-ce même Python ?

Guido: Je n'en ai vraiment aucune idée, et je ne suis pas sûr qu'il soit possible de répondre à cette question. Mon esprit a été formé par 14 ans de développement de Python; je ne peux pas imaginer ce qu'il serait si je ne l'avais pas fait.

Je ne pense pas aujourd'hui que j'aimerais créer un autre langage de programmation. Je ne crois pas en de gros changements révolutionnaires des concepts existants (mais les changements graduels et évolutifs ne s'arrêtent jamais, bien entendu). Par contre, je m'attends à ce que les changements révolutionnaires viennent d'éléments développés *au dessus* des strates existantes des systèmes d'exploitation, des langages et des bibliothèques. Peut-être inventerai-je l'un d'entre eux, ou peut-être serais-je satisfait d'avoir permis à la prochaine génération de magiciens d'explorer leurs idées plus rapidement, en développant en Python à la place du C.


DLFP: Et si tu avais à redévelopper Python de zéro, avec toute les connaissances que tu as accumulé à ce jour, que changerais-tu ?

Guido: J'ai fait une conférence un jour, « Python regrets. » On peut la trouver à cette adresse : http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.ppt


DLFP: Zope a gagné une popularité et une crédibilité toujours croissantes parmi les développeurs web. Comment vois-tu son évolution, d'ici quelques années ? [Julien Duponchelle]

Guido: Je suis un des développeurs principaux de Zope 3, la prochaine génération de Zope. Je suis très excité par les possibilités de Zope 3; il est bien meilleur que Zope 2. Je m'attends à ce que Zope 3 devienne un outil de développement web majeur.


DLFP: Si tu devais travailler pour une autre société que Zope Corporation, laquelle choisirais-tu ?

Guido: Ma propre entreprise d'expertise, aidant d'autres sociétés de développement à améliorer leur productivité en utilisant au mieux Python.


DLFP: Comment considères-tu des projets tels que le framework Twisted (http://twistedmatrix.com/products/twisted) ? Zope est particulièrement bon lorsqu'il s'agit de gestion de contenu web, tandis que Twisted est plus orienté vers les applications multi-protocoles. Mais, quelque part, je pense que les objectifs des deux projets vont peut-être se rejoindre. Es-tu d'accord ?

Guido: Je ne pense pas qu'une fusion des deux projets soit une bonne chose : il vaut mieux qu'il y ait de la compétition. Les développeurs de Twisted ont une vision très différente de celle des architectes de Zope. Je m'attends à ce que Zope apprenne de l'approche de Twisted pour l'implémentation de serveurs; soit Zope adoptera les couches basses de Twisted, soit Zope remplacera au moins son implémentation par quelque chose de similaire; et je m'attends à ce que Twisted reprenne des parties sélectionnées de Zope (telles que les interfaces). J'encourage les deux projets à séparer les parties qui pourraient être réutilisées à l'extérieur.


DLFP: Que penses-tu de PyZine (http://www.pyzine.com/) ? Le lis-tu ?

Guido: Je l'apprécie, et j'aimerais que plus de personnes s'y abonnent. Je le lis, et lorsqu'ils abordent des sujets concernant des applications ou des bibliothèques spécifiques, j'apprends parfois des choses.


DLFP: Qu'as-tu fait de ton prix pour les Free Software Award, reçu à l'occasion du FOSDEM de l'année dernière ? Est-il sur un des murs de ta maison ? :-) [Nicolas Roard]

Guido: Il est sur le mur du bureau du PythonLabs, au dessus de mon bureau. J'ai vraiment apprécié ma visite au FOSDEM.


DLFP: T'amuses-tu toujours en développant Python ? [Hervé C.]

Guido: Définitivement.


DLFP: Quelle question voudrais-tu que je te pose ?

Guido: Cet interview est-il déjà fini ? :-)

DLFP: Non, désolé, je ne te demanderai pas ça - je n'en ai pas encore fini avec toi. ;-)


DLFP: Quelle question ne voudrais-tu pas que je te pose ?

Guido: Je ne le dirais pas. :-)

DLFP: C'est une réponse facile ! :-)


Merci encore, Guido.






DLFP: Hi, Guido. It is nice to meet you, even if it is only electronically. Questions are coming partly from the users of linuxfr.org, and partly from me.

First, what would you like to say to non-Python users, so that they give Python a try - and optionnaly keep reading this interview ? When asking this question I especially think about people who already heard a bit about it, but did not found the motivation to try another language.


Guido: I would say, "resistance is futile -- you will be assimimated." :-)

Seriously, there are many different reasons why people haven't tried out Python yet, and for each one a different little push in the right direction might be sufficient to take a peek. Whether you're currently programming in C, C++, Java or Perl, Python has certain advantages that you should at least be aware of: clarity of expression, readability, maintainability, all in an attractive open source package with a large standard library and an even larger supply of open source third party software.


DLFP: One of the things I like in Python is its comprehensive, complete and easy-to-search documentation (http://www.python.org/doc/current/), as well as the possibility to document interfaces from within the code. Some goods things are coming regarding these two aspects, with the development of docutils (http://docutils.sourceforge.net/) and reStructuredText (http://docutils.sourceforge.net/rst.html). How do you see the benefits of such an approach ?

Guido: If desirable, it is possible to generate reference documentation for a project from its doc strings, although it requires that the programmer writing the doc strings is aware that he is writing user documentation. docutils and reST are the best tools available to produce readable documentation from doc strings.


DLFP: What do you think about literate programming (http://www.literateprogramming.com/) ? What about programming with an outlining editor (such as leo - http://personalpages.tds.net/~edream/front.html) ?

Guido: I like the idea of literate programming, but I haven't tried it myself. It would seem to me that literate programming is most useful when you are planning to write documentation explaining the code anyway, either in a tutorial situation or when you are specifically planning for maintenance by less-capable programmers. I've come across projects done using literate programming, and I've usually found myself impatiently reading the non-code parts. :-)

That said, I find the Leo project extremely valuable for other reasons.


DLFP: What are these reasons ?

Guido: The cool thing (for me) about Leo is that its author has tried a variety of different programming languages to implement this system (over more than a decade), and then decided to rewrite it all in Python.


DLFP: You said some time ago that a part of the Python community was afraid of how rapidly the language is evolving. I personnaly do not care, as long as each branch is supported and that Python keeps backward compatibility between each major release. I am even quite excited each time a new release is out, as it often adds a lot of useful bits to the language. How does this need to "slow down" modify the way Python is developped ?

Guido: Maintaining old versions costs a lot of effort. While working on Python 2.3, we still maintain Python 2.2 (2.2.2 was just out and we're already planning 2.2.3), and even Python 2.1 (we may release 2.1.4 at some point to fix a certain security bug). The effort takes several forms: you have to decide which fixes to the current release are important enough to backport; given how many fixes go into the current release, that's a non-trivial taks, and if you don't do it right away it's hard to forget. Then there's the effort to actually backport a fix. If you're lucky, it's a patch to one file and the patch applies cleanly to the older version. But as the current release gets cleaned up, refactored, and so on, the likelihood of patches applying cleanly to older versions goes down, so then there's real effort required for the backport. Plus, to be thorough, one needs to backport a unit test for the fix as well. And then there's the cost of issueing a release itself. If you take everything together (CVS tagging, generating a tarball, HTML, a Windows installer, updating the website, sending out announcements) that usually costs a few days of work. (Read PEP 101 and 102 to see how much care we take for releases.)

Maintaining backward compatibility also has a cost, even if we didn't maintain older versions: strict backwards compatibility makes it impossible to add new reserved words to the language, and thus severely restricts the possibilities for new syntax. Also, I have to admit that sometimes old features weren't designed as well as they could, but the backward compatibility requirement makes it hard to fix these. We usually find a way, but not without costs (e.g. you may have to add some magical incantation to each module that uses a new feature). Yet, I value backward compatibility because it is the only way to keep the community of Python users growing while allowing everybody to move on to a new version when they are ready.


DLFP: Are you evaluating the possibility of integrating wxPython (http://www.wxpython.org/) as Python's standard GUI ? It has a lot more of features than Tkinter. [Patrice Vetsel]

Guido: No; because of the different development cycles of wxPython and core Python, I think it's better of wxPython remains an add-on project. That said, I agree that it has more features than Tkinter, and I encourage people to check it out. There's really no need to restrict yourself to modules that are part of the standard distribution!


DLFP: Do you think projects like Psyco (http://psyco.sourceforge.net/), seeking for execution speed improvements, are really useful ? Will there ever be part of the standard distribution ? [Etienne Labaume, Patrice Vetsel]

Guido: I expect it will be a few years off, but I find Psyco extremely promising and I believe it will change the way we think about the performance of Python programs.


DLFP: What do you think of the Parrot project (http://www.parrotcode.org/), which aim is to develop a common virtual machine for interpreted languages, such as Perl 6, Python, Ruby and Tcl ? [Jean-michel Fayard]

Guido: I wish them well, but I don't think they will succeed. They are vastly underestimating the effort that goes into a virtual machine for any specific programming language. Even languages as similar as Ruby and Python have fundamentally different runtime abstractions, and the difference between Python and Perl is much greater still. (For example, the concepts of strings and numbers are entirely different in these two languages: in Python, numbers and strings are different immutable types, while in Perl they are the same type and are mutable.) I expect Parrot will do a great job of running Perl 6, but a relatively poor job of running other languages. Of course, I'd be happy if I were wrong (except for the brief moment of receiving a pie in the face at OSCON 2004), but I don't expect that to happen.


DLFP: Why, in your opinion, is Python less popular than other languages like Perl, PHP or Java ? This does not appear to be a problem of a lack of features... [bricabrac]

Guido: Is Python still less popular than Perl? :-)

Seriously, different reasons for each: Perl was there first, and Python is catching up; PHP is totally focused on simple web development, which happens to be very popular (but as sites grow, they tend to convert from PHP to Zope in order to stay manageable); Java has a big marketing machine.


DLFP: Can you tell us more about the various advantages native Python Web frameworks can offer to webmasters, compared for exemple to PHP or Perl? Is there any drawback ?

Guido: Sorry, that's not my area of expertise. All I know is the very high level view which is that using Python can lead to more maintainable code. It's apparently really easy to get started in PHP, and then end up with a big mess of spaghetti code.


DLFP: What do you think about C# ? .NET ? [maxoub]

Guido: Technically, these are good designs, but their technical merits are irrelevant; Microsoft uses these to secure its market dominance. While some parts are being reimplemented as open source, I expect that Microsoft will try to use patents to prevent some key parts being reimplemented, so that they will be able to claim superiority of their own implementation.


DLFP: Is there any project involving Python and .GNU (DotGNU - http://www.dotgnu.org/) ? [Etienne Juliot]

Guido: I don't know. I've never heard of dotgnu until you mentioned it.


DLFP: What is your opinion about Stackless Python (http://www.stackless.com), used for example by Eve Online, a Massive Multiplayer Roleplay Game (http://www.eve-online.com/faq/faq_08.asp) ? [Sidoine de Wispelaere]

Guido: Stackless is a fascinating hack. In its current form it doesn't meet the criteria for inclusion in the core, so I'm glad Christian Tismer
has agreed to keep it a separate project.


DLFP: I try to use Python to teach everyday people without any background in computer science (and no intention to get any) how to script simple things. Other softwares (Blender, PSP, Gnumeric) seem to use Python for the same thing : basic macros. One problem I have, though, is that to a non english-speaking person, the easy syntax of Python is kind of lost. Do you think of a way to introduce localized versions of Python ? [jm]

Guido: As far as I know the only localized version of Python in the sense that you mean exists in China, where someone maintains a version that allows Chinese alternatives for reserved words and identifiers.

In general I'm not in favor of doing this, and I doubt it makes much of a difference in this internet-enabled age. You may be able to localize the core syntax and a few key libraries, but at some point you will have to learn about the English words as well. In my experience, the concepts underlying programming are the the real stumbling block, not the words used to express them. And while you may not realize it, English speakers have problems remembering the names for things too!


DLFP: Is there any plan to introduce aspect oriented programming features to Python (http://aosd.net/) ? [Jiba]

Guido: Not that I'm aware of. If you're interested in this work, you can probably do most of this using metaclasses and multiple inheritance though.


DLFP: If you were starting developping Python today, what would it look like ? Would it be Python at all ?

Guido: I really have no idea, and I'm not sure it would be possible to answer this question. My mind has been formed by 14 years of developing Python; I can't imagine what it would be like if I hadn't done that.

I don't think at this point I'd like to design another programming language. I don't believe in big revolutionary changes to existing concepts at this point (but gradual, evolutionary change never stops of course). Instead, I expect that the revolutionary changes will come from things that are developed *on top* of the existing substrate of operating systems, languages, and libraries. Maybe I'll invent one of those, or maybe I'll be satisfied with having enabled the next generation of wizards to explore their ideas more quickly by developing them in Python instead of C.


DLFP: And if you had to re-developp it now from scratch, with all the knowledge you have accumulated so far, what would you change ?

Guido: I gave a talk once, "Python regrets". You can find it all there: http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.ppt


DLFP: Zope has gained an increasing popularity and credibility among web developpers. How do you see it, a few years from now ? [Julien Duponchelle]

Guido: I'm one of the core developers on Zope 3, the next generation of Zope software. I'm very excited about Zope 3's possibilities; it's much better than Zope 2. I expect Zope 3 to be a major web development tool.


DLFP: If you had to work for another company than Zope Corporation, which one would you choose ?

Guido: My own consulting firm, helping other software development companies improve productivity by using Python well.


DLFP: How do you see projects such as the Twisted framework (http://twistedmatrix.com/products/twisted) ? Zope is quite good on managing web content, whereas Twisted is more oriented towards multi-protocols applications. But, somewhat, I think the two projects' goals will eventually merge. Do you agree ?

Guido: I don't think a complete merge would be a good thing: let there be competition. The Twisted developers have a very different view of the world than the Zope architects. I expect that Zope will learn from Twisted's approach to implementing servers; either Zope will adopt Twisted's lower layers as its own, or at least Zope will replace its server implementation with something similar; and I expect that Twisted will borrow selected pieces of Zope (like interfaces). I encourage both projects to separate off parts of the project that could be reused outside the project's own context.


DLFP: What do you think of PyZine (http://www.pyzine.com/) ? Do you read it ?

Guido: I like it, and I wish more people subscribed to it. I do read it, and when they discuss specific applications or libraries I sometimes learn from it.


DLFP: What did you do of your prize for the Free Software Award you received at the FOSDEM last year ? Is it on one of your house's walls ? :-) [Nicolas Roard]

Guido: It's on the wall of the PythonLabs office, above my desk. I really enjoyed my visit to FOSDEM.


DLFP: Do you still have fun developping Python ? [Hervé C.]

Guido: Definitely.


DLFP: What question would you like me to ask you ?

Guido: Is this interview over yet? :-)

DLFP: No, sorry, I will not ask you that - I am not yet over with you. ;-)


DLFP: And what question would you like me not to ask you ?

Guido: I won't tell. :-)

DLFP: That was an easy answer !


Thank you again, Guido.
  • # Re: Interview de Guido van Rossum (Python)

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

    Et pour ceux qui seraient maintenant tentés de l'essayer,
    on peut le télécharger sur :
    http://www.python.org/2.2.2/(...)
    et de la doc sur :
    http://www.python.org/doc/current/(...)

    A noter, pour montrer que c'est vraiment actif, qu'une version alpha est sortie tout recemment (le 19 février) :
    http://www.python.org/2.3/(...)
  • # Re: Interview de Guido van Rossum (Python)

    Posté par . Évalué à 10.

    Très bonne interview. Félicitations.

    J'ai commencé à me mettre à Python il y'a quelques temps, en réalisant que la majeure partie de mon système se basait dessus (une gentoo avec ROX comme environnement), et j'ai vraiment apprécié.

    Et j'aime bien la façon dont "papa Python" parle de sa progéniture, et ca me conforte un peu plus dans mon apprentissage de ce langage.
  • # Re: Interview de Guido van Rossum (Python)

    Posté par . Évalué à 10.

    Desolé de lancer ce que certains appeleront un troll mais j'aimerais qu'on m'explique une bonne fois l'interet de faire un language entierement controlé par l'indentation.

    Python est bien , plein de fonctionnalites , mais ce controle par l'indentation m'a toujours donné des boutons.

    Certain disent que c'est plus clair . J'ai devant les yeux 2500 lignes de python , c'est loin d'etre clair . En tout cas pas plus que les autres fichiers en perl , c , c++ dont je m'occupe.

    A contrario qd on fait une modif dans du code python, quand on utilise un editeur different de celui d'origine, on a souvent plein de problemes vicieux simplement parce qu'un bout de code a ete deplacé incorrectement. En bref, quand on cree ex-nihilo c'est parfait, mais quand on doit maintenir ou modifier quelque chose fait par d'autres , c'est la galère.

    Bref j'aimerai entendre les arguments. En particulier ceux de ceux d'entre vous qui connaissent (bien) plusieurs langages et les fonctions de mise en forme tres puissantes de certains editeurs comme emacs.
    • [^] # Re: Interview de Guido van Rossum (Python)

      Posté par . Évalué à 10.

      J'ai longtemps été réticent à utiliser Python à cause de ce simple fait. Pour moi, un langage qui incluait la mise en forme dans sa grammaire, c'était conceptuellement biaisé.

      Mais dans la pratique, c'est vraiment pas désagréable. Ca allège franchement la syntaxe (finis les {} du C), et ca garantit d'avoir un code mis en forme de façon claire.
    • [^] # Re: Interview de Guido van Rossum (Python)

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

      je ne répondrais que par une question ;
      quel est l'interet de faire un langage utilisant des accolades ?
    • [^] # Re: Interview de Guido van Rossum (Python)

      Posté par . Évalué à 10.

      Il y a deux choses par rapport à l'indentation

      La saisie:
      - Il faut s'y habituer, ensuite on ne veux plus s'en passer. Le problème, c'est qu'en revenant sur d'autres langages on oublie fréquement les {, ; $... C'est à ce moment là que l'on s'aperçoit à quel point ils sont inutiles et pesants.

      La lecture:
      - Elle est instantanée. Je veux dire par là qu'il ne peut pas y avoir de piège de la sorte
      if (c==5)
      printf ("ok");
      printf ("suite");
      - Plus agréable et plus rapide, du fait qu'il y ait beaucoup moins de signes ; { $ etc...

      - Je ne partage pas ton point de vue, par rapport à d'autres langages comme le C ou le PHP, c'est la première fois que je prend plaisir à hacker d'autres sources. En particulier les miens ! (dont la maintenance est beaucoup plus facile)
      • [^] # Re: Interview de Guido van Rossum (Python)

        Posté par . Évalué à 10.

        if (c==5)
        printf ("ok");
        printf ("suite");

        ca c'est mauvais, je suis d'accord
        mais rien ne t'empeche de l'ecrire comme en Python ,ce que fait d'ailleurs l'indentation automatique des editeurs :

        if (c==5)
        printf ("ok");
        printf ("suite");


        La bonne syntaxe, c'est celle de perl :

        print ("ok") if (c==5);
        printf ("suite");

        là il n'y a pas d'ambiguité ni de risques.
        • [^] # Re: Interview de Guido van Rossum (Python)

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

          En ce qui concerne les problèmes d'intentation, choisi de toujours utiliser la touche tab par exemple et tu auras moins de problèmes. (Enfin, j'ai pas essayé de retoucher mon code python en prenant 36 éditeurs, mais je n'ai pas trop de problèmes). A vrai dire, c'est une autre vision que le perl, mais force est de constater, que même si en perl on peut tout faire comme on veut, il y a des façon de faire qui sont plutôt suivies et conseillées. Cette rigueur apportée à python est à mon avis pas du tout une contraire, pour autant qu'on commence à y coder sérieusement. (J'ai mis 10 minutes à m'habituer à l'indentation, pas plus).

          Le même code en python :

          if c == 5 : print 'ok'
          print 'suite'
    • [^] # Re: Interview de Guido van Rossum (Python)

      Posté par . Évalué à 10.

      Une fois que t'as bossé sur de gros code, fait par plusieurs dev ayant chacun leur éditeur, leur plateforme (VisualC, emacs, vi), tu es bien content d'avoir une mise en forme stricte et unique
      Car une fois que tu fais joujou avec des outils de versionning on te fais vite comprendre qu'il est hors de question de reprendre le code pour l'indenter correctement (ce qui ne veux rien dire en C/C++), histoire de limiter les diff a ce qui a vraiment changé.

      Au final c'est peu etre contraignant et impose une vision "unique", mais une fois l'habitude prise ca deviens naturel et on passe vraiment au codage.
      • [^] # Re: Interview de Guido van Rossum (Python)

        Posté par . Évalué à 7.

        cleartool diff -blank_ignore ...
        Ah c'est vrai... c'est limité à certains outils de gestion de configuration ;o)

        Trève de plaisanterie/troll, je suis parfaitement d'accord avec ta vision des choses concernant :
        1. le non-respect des méthodologies "qualité" (spécifications de langage, méthodes de développement...) par une majorité de développeurs
        2. la facheuse habitude des tabulations dans les éditeurs (emacs, vi/vim...) qui rendent le code illisible.

        d'ailleurs, les set tabstop=3 et set expandtab, ça n'a jamais fait de mal à personne sauf... pour les Makefile et les indentations des End-Of-File pour les commandes shell cat, ed...


        Mais si cet aspect peut s'avérer très gênant à la longue, cela justifie-t-il l'investissement dans un nouveau langage ?
        (encore que, ne connaissant pas Python, tout ce que j'ai lu ici m'invite à la découverte ;o)
        • [^] # Re: Interview de Guido van Rossum (Python)

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


          > cleartool diff -blank_ignore ...
          > Ah c'est vrai... c'est limité à certains outils de gestion de configuration ;o)


          Uh ?
          genre, diff -b/-w/-B ?

          Je ne pense pas que ce genre d'options soient spécifiques à des outils propriétaires (je ne connais pas cleartool, mais vu le nom, je suppose que ça vient de clearcase ?)

          seb.
      • [^] # Re: Interview de Guido van Rossum (Python)

        Posté par . Évalué à 3.

        J'ecris du code python depuis un an, pour un projet de chaine de EDA libre, et j'ai eu aucun probleme pour prendre l'habitude de l'indentation.
        Par contre on a eu une personne qui a commence a ecrire du code python pour notre projet et la on s'est apercu de la fausse souplesse de cette mise en forme imposee.

        En effet elle est loin d'etre stricte, on peut utiliser des tabs, ou des espaces, on peut melanger les deux, mais surtout on peut melanger la maniere dont on met en forme au sein du meme code !!! Ce qui a mon sens est une erreur, parce que cela va a l'encontre de du but de Python, on peut ecrire du code illisible en melangeant les types d'indentation, car
        apres selon ton editeur cela ne va pas donne la meme mise en forme ( si tu as les tabulations a 4 ou 3 ou 8 caracteres, et que par endroit tu indentes avec des espaces ca met un beau foutoir).

        Ceci etant dit, l'utilisation de l'indentation a la place des accolades semble plus une question de gout et de couleur qu'autre chose, ce n'est pas du tout la que reside la force de python, c'est juste un extra qu'on aime ou qu'on aime pas ( un generateur de troll en quelque sorte :)
        • [^] # Re: Interview de Guido van Rossum (Python)

          Posté par . Évalué à 0.

          voila , c'est exactement ca . J'ai tres exactement la meme experience .
          Tant qu'on ne peut pas obliger d'utiliser des blancs au lieu des tabulation, fixer le nombre de blancs ,...etc ca fait un beau foutoir

          C'est dommage.
  • # Re: Interview de Guido van Rossum (Python)

    Posté par . Évalué à 1.

    Existe-t-il un livre que vous recommanderiez pour l'apprentissage du Python, il a l'air intéressant, au moins autant que le Ruby...

Suivre le flux des commentaires

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