L'Atelier Python 2006 de Vancouver

L'utilisation de Python au Brésil fut abordée par Leonardo Rochael Almeida. En 2002, le président du Brésil Lula et son parti avaient décidé de soutenir les logiciels libres. Parallèlement à cela Serpo™, l'entreprise gouvernementale d'informatique, voulait ouvrir les agences gouvernementales à Internet, et recherchait un système de gestion de contenu (CMS [content management system]). Serpo™ rencontra alors Paul Everett de Zope, qui participait à une conférence sur Linux au Brésil, et décida d'utiliser Plone. (Zope est une application Internet de type "cadre d'application" [framework] écrite en Python; Plone est un CMS placé au dessus de Zope.) Leonardo convertit le portail internet de Serpo™ de IIS/ASP à Plone en deux semaines, et un employé aveugle de Serpo™ en fit la démonstration au Comdex-br™.Plone fait maintenant tourner 120 sites nationaux et régionaux y compris le portail principal du Brésil, le site du président, et les sites du Parlement (la Câmara dos Deputados et le Senado). Le Parlement a choisi Plone en lieu et place de Oracle, Vignette,MS SharePoint et IBM WebSphere pour ses caractéristiques et sa simplicité d'utilisation, et pas pour son prix. Les deux sites couvrent les activités parlementaires, les lois en vigueur, la finance et les ressources humaines. Le même système de gestion a été dupliqué pour les administrations locales.

Autre application Python : Projecto Presença, qui est un programme de fréquentation scolaire couvrant 206 000 écoles publiques (50 000 de plus sont prévues). Oui, au Brésil, Big Brother sait si vous êtes allés à l'école ou non. Projecto Presença est une application Web écrite en CherryPy, SQLite, et utilisant les gabarits de page[templates] Zope. Une interface Web a été choisie car les écoles possèdent des systèmes d'exploitation différents. Cependant elle tourne seule en local, à cause des disponibilités sporadiques d'Internet. Grâce à ce travail et aux autres sites, Python a gagné suffisamment de crédibilité pour être maintenant envisagé pour tous les projets de programmation du gouvernement, et qu'il est régulièrement choisi.

Plusieurs autres organismes au Brésil utilisent les applications Python également, parmi elles 4FS Consulting™, IDG Now™, CTBC Telecom™,AOL-br™, Bank Boston™, et Nokia™. L'exemple le plus intéressant est un logiciel de suivi des marchandises. Le Brésil a un problème avec les voleurs dérobant les camions de livraison, des camions suivis par GPS seraient inutiles car les voleurs déchargeraient alors la marchandise dans un second camion et abandonneraient le premier. Ils utilisent donc désormais un système allemand embarqué directement dans le chargement, qui mesure la proximité des émetteurs de téléphonie mobile locaux et envoie un SMS avec leur numéro d'identification et leur distance à un serveur central qui se charge alors de calculer l'emplacement exact de la marchandise.

Nokia™ a construit un centre de recherche au Brésil. ("Il s'avère justement se trouver à proximité d'une plage de rêve.") Là bas, Nokia™ a inclus Python à sa Tablette Internet 770, qui fait tourner un dérivé d'une Debian Linux™ sur un processeur ARM™. Nokia™ a contribué au code en amont, y compris "un grand nombre de tests" de la pile Linux Bluetooth, et des optimisations pour Python/ARM. Ils ont également rendu compatible l'appareil pour Tapioca VoIP. (Tapioca possède des liaisons Python PyTapioca). Trois personnes à la conférence possédaient cette petite tablette Nokia™ ("Ce n'est pas un téléphone!"), et j'ai trouvé cela très astucieux; je suis en train d'écrire un article dessus pour le prochain numéro.

L'exposé de Guido portait sur Python 3.0 (aussi connu sous le nom de Python 3000, qui sera disponible dans sa version alpha début 2007, et en version finale un an plus tard. Il s'agira d'une version incompatible avec les versions précédentes de Python, "une occasion de réparer les erreurs de conception du début, pour la plupart de 1990-1991, comme les classes classiques, la dichotomie Unicode/chaînes de caractères, et la division des entiers." Les versions 2.x continueront à être compatibles pendant 2-3 ans, cela dépendra de la rapidité avec laquelle les utilisateurs passeront à la version 3.0. Quelques caractéristiques de cette version seront ajoutées aux versions 2.x.

Python 3000 aura des nouveaux mots-clés, avec dict.keys() et consort, on obtiendra un itérateur ou une "set view" plutôt qu'une liste, print sera remplacé par une (ou des) fonction, le type str sera en Unicode, unicode disparaîtra, et un nouveau type de bytes mutables permettra de traiter les tableaux d'octets (et les textes encodés sur 8 octets comme les UTF-8). Cela nécessitera un nouveau sous-système d'entrée/sortie pour manipuler les nouveaux types. Tout ceci a été décidé, mais cela va prendre une bonne année pour écrire le code et se sortir des inévitables problèmes d'implémentation. Par exemple, Guido veut abandonner la bibliothèque stdio du C pour les entrées/sorties, argumentant que les différences entre les deux plates-formes sont trop lourdes.

Le type bytes (octets) sera un tableau d'entiers, ints, chacun compris dans une gamme de 0 à 255 (range(256)). Il y aura quelques méthodes qui auront l'air d'être basées sur les chaînes, comme .find, mais aucune méthode carrément basée sur les chaînes telles que .upper. La "set view" mentionnée plus haut est empruntée à l'interface Collection de Java, qui est apparemment plus légère et plus souple dans ce cas.

Une autre nouvelle caractéristique examinée par Guido est la surcharge de fonctions. Il s'agit d'une fonction appelante qui répartit vers une ou plusieurs autres fonctions selon les types d'arguments de la fonction appelante. Cela résoudrait le problème de l'adaptation, mais d'une façon très générale. (On entend par adaptation le fait de rendre compatible un objet avec un protocole, comme "un objet de type de dictionnaire", ou encore "un objet de type fichier".) Les fonctions surchargées seraient principalement utilisées par les concepteurs de cadres d'applications ou de bibliothèques plutôt que par les utilisateurs finaux.

Un outil de type pychecker peut probablement faire 80% du travail de mise à niveau des programmes Python, mais les 20% qui restent devront être faits à la main. Une version future de Python 2aura peut-être des alertes optionnelles sur le code qui se comporteront différemment (ne seront pas les mêmes sous Python 3.

Ceux qui veulent suivre ce qui a changé et ce qui n'a pas changé peuvent aller voir PEPs 3000-3999, le blog de Guido, et la liste de diffusion Python 3000.

L'intervention liminaire de Jim Hugunin portait sur "IronPython: Python dans dans le monde du .NET". Jim est l'auteur original de Jython (Python pour la machine virtuelle Java), et travaille maintenant chez Microsoft™ sur IronPython, qui permet de compiler des sources Python en "Langage Commun d'Exécution" (Common Language Runtime, CLR) .NET. Les programmes tournent jusqu'à deux fois plus vite sur IronPython par rapport au CPython, et ceci du fait de l'optimisation approfondie du CLR. Le CLR a à l'origine été développé pour le C ++ et le Visual Basic, mais a été intentionnellement rendu neutre par rapport au langage. MS™ maintient un site de type SourceForge pour IronPython sous une licence de type (Oh!) BSD. (Ou ce que MS™ pense être une licence de type BSD; on peut trouver la licence elle-même ici. D'autres la commenteront sûrement mieux que moi.)

Les utilisateurs Linux qui se sont endormis avec tout ce blabla sur Microsoft™, voudront peut être vérifier comment le projet Mono se présente, et voir si IronPython marche bien avec.

Depuis la dernière conférence de Jim au PyCon 2005™, IronPython a sorti pratiquement une version 1.0. (La version finale est attendue pour plus tard dans l'année.) Il s'intègre à Visual Studio, et dans une version future, à PowerShell 1.0. PowerShell est "la prochaine génération de shell Windows", combinant les caractéristiques d'un shell Unix traditionnel avec les caractéristiques d'un langage OO. Jim fit la démonstration de ce qu'on pouvait faire avec PowerShell comme bibliothèque à l'intérieur de Python:

>>> from powershell import * </command>
>>> shell.get_service(name="*")</command>
[... prints a list of running services (daemons) ...]

Vous pouvez également appeler d'autres bibliothèques CLR depuis Python et vice-versa, intégrer un interpréteur Visual Basic dans Python (il en fit une démonstration interactive), et d'autres exploits inter-langage. Il fit la démonstration de l'appel d'une bibliothèque Visual Basic pour jouer un son:

>>> My.Computer.Audio.Play("tada.wav")

Un problème de conception qui est apparu est l'incohérence des noms de méthode entre Python et .NET. Pour enlever les espaces aux deux extrémités d'une chaîne de caractères Python nous fournit la méthode s.strip(), tandis que .NET la nomme s.Trim(). Jim a décidé qu'un "programme Python doit se comporter comme un programme Python par défaut", si bien que seul s.strip est autorisé à moins que vous n'exécutiez un import clr pour amener les méthodes CLR. Heureusement, les méthodes CLR comportent des majuscules, elles n'entrent donc pas en conflit avec les méthodes Python.

Enfin, Jim fit la démonstration de Merlin, qui est probablement Clippy déguisé en assistant. Mais ce Merlin répond aux commandes vocales.

Ian Bicking nous a présenté WSGI, le protocole qui permet à des applications Web provenant de différents cadres d'application Python de communiquer. (WSGI fera bientôt parti de la bibliothèque Python standard.) Ian appelle WSGI "une série de tubes", qui comme les canaux de transmission ["pipes"] Unix permettent de connecter des petites routines spécifiques dans un plus grand ensemble. Les diapos sont disponibles ici (fichier ODP, OpenOffice.org requis), mais le point fort était ce diagramme d'une application Web hétérogène faite d'une douzaine d'unités indépendantes. Le diagramme est sympa, il est fait au crayon de couleur!

David Ostrowski du laboratoire de recherche Ford™ nous a décrit comment il a utilisé AJAX et Jython pour concevoir des chaînes d'assemblage automobiles. c'est un travail compliqué de planifier toutes les tâches nécessaires à l'assemblage d'une voiture, et d'en répartir la charge équitablement pour les ouvriers de manière à ce que l'un ne soit pas surchargé tandis qu'un autre se tourne les pouces. Le programme calcule en unités de temps nécessaires pour terminer les tâches les plus courtes, et donne le temps global requis pour achever l'opération entière. L'application existante utilisait une combinaison non compatible JVM + XML + AJAX. David a utilisé Python pour convertir un fichier source Excel/VB en XML, puis une transformation XSLT pour produire un VRML, qui permet à l'opérateur de visualiser le dessin d'une voiture en 3-D et de le faire pivoter. Un service Web convertit XML en VRML pour les programmes clients. Python a maintenant gagné beaucoup de crédit auprès de Ford™.

Il y a eu quatre présentations sur Plone, avec entre autres un panel qui a débattu sur "Le Passé, le Présent et le Futur", et un exposé sur la façon de personnaliser l'apparence de Plone. Le panel fit remarquer que la plupart des concurrents de Plone étaient commerciaux, et qu'il soutenait favorablement la comparaison avec des systèmes coûtant entre 20 000$ et 200 000$. Plone ne possède pas beaucoup de concurrents open-source. Dupral n'est pas réellement un concurrent puisqu'il occupe un marché différent. (Ils n'ont pas précisé ce qu'ils entendaient par là.) Plone possède maintenant plus de 200 modules d'extension externe [add-ons] créés spécialement pour lui.

Les éditeurs de la Gazette Linux ont jeté un oeil sur Plone récemment et ont été assez impressionnés. Nous migrerons la Gazette sur Plone dès le mois prochain. (Je rigole!)

Il y a eu un exposé sur le statut de PyPy. PyPy est un interpréteur Python écrit en Python. (En fait il est écrit en RPython un sous-ensemble qui s'adapte bien au statique de Python.) Le temps de gestion tient maintenant en un seul chiffre, alors qu'il était 1000% moins rapide l'an dernier. La version 0.9 est disponible; elle a obtenu des résultats positifs à 95% des tests du noyau Python. PyPy compile en code octet Python, et il peut aussi compiler vers du C natif ou du .NET. La qualité de PyPy ne tient pas dans le fait que les utilisateurs voudront faire tourner leurs applications dessus, mais qu'il constitue un environnement de développement simple pour tester les améliorations de l'interpréteur.

Wilson Fowlie a présenté PyParsing, qui est comme un moteur d'expressions régulières à la différence près que la règle de tri n'est pas construite avec une chaîne de caractères ASCII mais avec des méthodes et des constructeurs d'objets réguliers. Wison n'est pas un des développeurs de PyParsing; il est "seulement" utilisateur : quelqu'un qui trouve que c'est utile dans son travail. Voici un exemple de PyParsing:

>>> rule = Literal("The") + "quick" + "brown"</command>
>>> rule += Word("P", "hnoty")</command>
>>> rule.parseString("The quick brown Python")</command>
["The", "quick", "brown", "Python", {}]</command>

(La dernière règle correspond à tous les mots qui commencent avec la majuscule "P" et contiennent seulement un caractère appartenant au jeu "hnoty". Cela correspondrait aussi à "Pyythoon".) Vous pouvez aussi faire correspondre un mot à une expression régulière si vous y tenez vraiment. PyParsing peut aussi faire certaines choses que les expressions régulières ne peuvent pas faire, comme faire correspondre les parenthèses ouvrantes et fermantes et traiter les expressions qui s'y trouvent. Et on peut spécifier une clé pour chaque règle, de sorte que la valeur est accessible à la fois par l'index et par l'attribut.

Brian Quinlan a présenté Avalon, l'API nouvelle génération de l'interface graphique de Microsoft™. Il nous a montré un jeu de type Pong en Python qui pouvait changer son apparence en se basant sur un fichier XML. Est-ce que vous voulez que vos maillets ressemblent à des pixels blancs tout carrés, ou à des images de la Terre et de Mars en guerre? Le fichier XML peut également modifier le comportement du jeu en lui-même, en donnant par exemple un désavantage aux Martiens en leur donnant un maillet plus court, ou en les plaçant plus près du centre. Faites attention aux jeux vidéo dont les fonctionnalités se trouvent sur des serveurs distants, et plus spécialement si vous avez des ennemis.

Il y a également eu des exposés sur l'utilisation de l'environnement Macintosh™ Cocoa, construisant des applications Mac avec py2app et Windows avec py2exe. Apparemment il y avait un problème avec les discussions Mac qui changeaient leur titres et ne collaient pas avec le sujet.

Côté tutoriel, on nous offrait une présentation permanente sur le Python, plus une session de formation rapide de deux heures sur Plone. Le tutoriel Python fut bien suivi (40 personnes), mais certains se sont plaint qu'il était d'un niveau trop élémentaire. On pourra peut-être en tirer la leçon pour l'année prochaine, définir le public visé et l'indiquer aux participants. Les programmeurs qui sont néophytes en Python ont besoin d'un tutoriel différent par rapport à ceux qui n'ont jamais programmé auparavant. Certaines personnes savent ce que sont les "floats" et la programmation orientée objet, d'autres non. Des tutoriels de niveaux "débutant" et "intermédiaire" sont peut-être nécessaires.

Les Exposés éclair sont de courts exposés de 5 minutes, ils ont beaucoup de succès lors des conférences Python. Comme exposés, on a eu :

C'est une bonne transition pour passer au discours de clôture de Ian Caven,"Python monte à Hollywood". Ian a fondé une petite société pour améliorer les grands classiques du cinéma en numérisant les films et en remettant la version numérique sur support film [film-to-digital-to-film] avec des <trademark>Macintosh</trademark> G4 que l'on trouve dans le commerce. Les acheteurs attendent des films sur DVD qu'ils soient léchés (avec des images d'une grande netteté et d'une bonne luminosité) même si le film original ne l'était pas. Il a commencé avec un petit groupe de 18 G4 commandés par un iMac, et possède maintenant 550 G5 dans une grande salle. ("Je ne peux pas les allumer tous en même temps. Ma facture d'électricité est de 5000$ par semaine.") Initialement il programmait en C/C++, mais il est passé au <application>Python</application>, et utilise le paquet <application>Python</application> <code>Numeric</code> pour les calculs rapides sur matrices, et <application>Zope</application> comme interface utilisateur sur les contrôleurs. Son objectif a été dans un premier temps de faire en sorte que ça marche, puis d'améliorer la rapidité, la qualité et d'ajouter des fonctionnalités. Ce qui est étonnant, c'est que Ian a été le seul développeur pendant plusieurs années, travaillant avec un seul collaborateur. Maintenant cette société emploie quelques 24 personnes. Elle était à l'origine nommée <trademark>Lowry Digital Images, Inc.</trademark>, mais est maintenant détenue par <trademark>Digital Theater Systems</trademark> (DTS).

Ian travailla d'abord sur un film, puis sur un autre, par exemple "North by Northwest" et "Citizen Kane", et obtint petit à petit des contrats de plus en plus gros, entre autres la série des Star Wars et celle des James Bond. Sa société a à ce jour traité plus de 150 films, y compris la plupart des dessins animés Disney™ qui sont actuellement disponibles.

Ce fut un week-end bien rempli à Vancouver. On eu droit samedi soir à la finale d'un concours annuel de feux d'artifices, alors tout Vancouver et beaucoup des Pythoniers se sont retrouvés sur les plages pour assister à la représentation de 30 minutes de l'équipe du Mexique, qui gagna le premier prix. Dimanche eût lieu la Gay Pride de Vancouver. Lundi était férié pour cause de "BC day", jour férié en Colombie Britannique. Et étant donné que je travaille sur les marées noires en haute mer, quelle ironie du sort de voir qu'une marée noire survenue vendredi au large de la ville voisine de Squamish faisait la une des journaux.

Vancouver est une ville géniale, spécialement si vous aimez comme moi les grands environnements urbains, denses et piétons. L'hôtel où la conférence se tenait était dans "un centre commercial suburbain", mais cela ne lui rend pas justice. Le centre commercial, l'hôtel et plusieurs magasins voisins sont reliés par des places, des trottoirs, des passerelles pour traverser la rue, si bien qu'ils sont accessibles à pied depuis le métro aérien sans avoir à traverser le moindre parking ou la moindre route. Les restaurants et le centre ville étaient donc faciles à atteindre depuis l'hôtel, et constituait le meilleur environnement que j'ai jamais vu pour une conférence.

Voici des éléments qui ont contribué à la réussite de cette conférence et que je n'avais jamais vus avant:

Ce qui n'a pas marché si bien que ça:

L'atelier de Vancouver est une petite variante régionale du PyCon™ avec quelques idées nouvelles. Il ne couvrait pas la programmation noyau de Python, et il n'y avait pas de sprints, et les exposés étaient plus axés sur "comment faire les choses" plutôt que "ce que je fais" ou encore "voilà ce qu'est ce paquet". Je ne sais pas si c'était intentionnel ou une coïncidence, mais cela donnait à l'atelier un côté pratique. Quelques auditeurs se sont plaints de la qualité d'un exposé ou d'un autre, et j'ai moi-même trouvé que certains ne correspondaient pas à ce que j'attendais d'après le titre, mais ce sont des erreurs qui se produisent dans toute nouvelle manifestation, et ces choses vont vraisemblablement s'améliorer si les organisateurs décident de reconduire l'atelier Python de Vancouver. Le premier atelier eu lieu il y a deux ans, nous attendrons pour voir si il y en aura un troisième. Et il ouvre peut-être la voie pour les "Conférences de la Côte Ouest" et les "Conférences Régionales" que certains réclament à cor et à cri.