veille Osterrath Rapport de veille Mai 2013 - ofti.org · et statiquement typés tels que le C/C++ ne se prêtent pas toujours aussi bien aux ... Le typage dynamique offre des avantages

Rapport de veille

Utilisation du langage de programmation Python et de son écosystème dans le domaine de la science

Une étude de cas pour la recherche dans le domaine de la reconnaissance de la parole

Première version

Frédéric Osterrath Agent de recherche senior

Reconnaissance de la parole Le 21 mai 2013

Partenaire financier :

Rapport de veille Utilisation du langage de programmation Python et de son écosystème dans le domaine de la science Une étude de cas pour la recherche dans le domaine de la reconnaissance de la parole

Tous droits réservés 2013 CRIM Le 21 mai 2013 Page 2

TABLE DES MATIÈRES

TABLE DES MATIÈRES ............................................................................................. 2

1. PROBLEMATIQUE .............................................................................................. 3

2. REVISION DES CARACTERISTIQUES DU LANGAGE PYTHON ............................................ 4

3. OUTILS D’INTEGRATION ET D’EXTENSION ................................................................ 6

4. REVISION DE L’ECOSYSTEME SCIENTIFIQUE DE PYTHON .............................................. 7

4.1 La pile Scipy ............................................................................................ 7

4.2 Routines numériques optimisées .................................................................. 8

4.3 Installation de la pile Scipy .......................................................................... 8

4.4 Comparaison avec MATLAB .......................................................................... 9

4.5 IPython comme environnement d’expérimentation ......................................... 10

5. CONCLUSION ................................................................................................. 12

GLOSSAIRE......................................................................................................... 13

ANNEXE ............................................................................................................ 14



1. PROBLÉMATIQUE

La validation des hypothèses et des concepts en recherche passe souvent par l’implémentation d’algorithmes permettant de conclure sur l’efficacité d’une méthode en observant ses effets sur des données expérimentales. Le chercheur passera donc beaucoup de temps à programmer tout en modifiant continuellement les processus développés, même si l’implémentation elle-même n’est pas le but premier de son travail. Ses outils se doivent donc d’être flexibles et agiles.

Le traitement de la parole est une tâche intensive qui demande une efficacité des programmes en exécution. Ainsi, les systèmes de traitement de la parole ont été traditionnellement implémentés en utilisant des langages permettant une bonne optimisation de l’utilisation des ressources système. Conséquemment, le C ou même le C++ ont été et demeurent des langages très populaires en reconnaissance de la parole. Il y a donc un large patrimoine de solutions informatiques que les chercheurs voudraient réutiliser sans avoir à les programmer à nouveau suivant l’avènement de nouvelles approches algorithmiques ou même de nouveaux paradigmes d’exploitation (e.g. :SaaS).

Or, dans la perspective du travail expérimental d’un chercheur, les langages compilés et statiquement typés tels que le C/C++ ne se prêtent pas toujours aussi bien aux exigences de flexibilité du travail expérimental que les langages dits de « scripts » tels que Perl, BASH/CSH, etc. C’est pour cela que bon nombre de solutions de reconnaissance de la parole utilisées dans la recherche (Kaldi, CMU Sphinx) sont en fait un assemblage de langages compilés et interprétés. Les logiciels compilés sont typiquement encapsulés en tant que processus distincts par des scripts permettant une exploration facile des variantes algorithmiques, mais cela amène un bon nombre de désavantages et contraintes logicielles causées par ce découplage. Citons par exemple la nécessité, souhaitable ou non, de passer par des données transitoires dans des formats et interfaces variés causant une explosion des types. Par ailleurs, les traitements numériques ou statistiques sont souvent réalisés avec des langages tels que Fortran, MATLAB ou R, en raison de leur expressivité pour ces tâches, ajoutant une autre base de code.

Finalement, mentionnons la tendance lourde de la diminution du prix de la vitesse de calcul et l’augmentation du coût de la main d’œuvre spécialisée en recherche. Si à une époque il était beaucoup plus dispendieux de mettre la main sur des processeurs très rapides, on peut dire que cela est une considération contemporaine moins importante avec la prolifération des solutions de grappes de calcul et d’infonuagique plus facilement accessibles. Or, l’exploitation de ces solutions se doit d’être standardisée et facile. Ainsi, il devient généralement plus important pour un gestionnaire de recherche d’optimiser le temps de développement d’une solution et de valoriser une polyvalence future, garante d’une plus grande valeur patrimoniale, plutôt que d’optimiser le temps d’exécution de cette même solution, sans dire pour autant que cela n’a plus d’importance.

Tous les éléments mentionnés ci-haut posent un certain nombre de dilemmes dans les choix technologiques des chercheurs et il y a des approches diverses pour tenter de répondre aux priorités les plus pressantes de chacun. Or, chaque approche apporte son lot d’avantages et d’inconvénients et il devient parfois difficile à accorder l’une avec



l’autre. Plus précisément, l’éventail des technologies informatiques qu’une équipe de recherche doit maîtriser pour mener à terme son travail semble être en perpétuelle expansion. Dans un tel scénario, il apparaît donc le désir chez plusieurs chercheurs de recentrer les technologies nécessaires vers un noyau commun couvrant les besoins d’un plus grand nombre de tâches dans le souhait de se concentrer d’avantage sur le sujet de recherche que sur les outils employés.

C'est dans ce contexte que nous allons regarder l’utilisation du langage de programmation Python. L’utilisation de Python dans le domaine de la science est en nette croissance depuis la parution de la version 2.0 du langage, soit vers l’an 2000. De nombreuses librairies vouées au traitement scientifique et numérique en plus d’outils de tout genre et ont été adoptés par un bon nombre de laboratoires de recherches prestigieux (CERN, Google, Nasa, etc.). Des conférences telles que EuroSciPy et PyData, entre autres, sur l’utilisation de Python en science et en traitement des données ont vu le jour, confirmant la tendance. De plus, mentionnons que la conférence généraliste PyCon aura lieu à Montréal en 2014 et en 2015.

Nous présentons dans ce document une révision des propriétés et tendances courantes dans l’utilisation de Python dans le domaine de la science, ainsi que quelques comparaisons avec des solutions comparables offrant ainsi un débroussaillage des éléments intéressants qui pourraient s’avérer utiles pour autrui. Ce document est accompagné d’un autre rapport sur les capacités de parallélisation de Python ainsi qu’un autre sur la solution de stockage des données que propose PyTables.

2. RÉVISION DES CARACTÉRISTIQUES DU LANGAGE PYTHON

Python est un langage de programmation général, multi-paradigmes, dynamiquement typé et est interprété à l’exécution. Il s’agit d’une solution logiciel libre dotée d’une licence permettant l’exploitation commerciale sans restrictions.

Dans Python, tout est un objet et toutes les opérations sur les objets s’effectuent par une référence sur l’objet en question, sauf dans quelques rares exceptions. Le typage dynamique des objets ne permet généralement pas la translittération des types à l’exécution, sauf dans le cas d’opérations, mathématiques ou autres, qui auraient du sens.

Le typage dynamique offre des avantages au niveau du temps de développement et de la flexibilité du code produit. Par exemple, le cas suivant nécessiterait considérablement plus de lignes de code en C/C++ ou en Java :

def square ( a ) :

return a * a

>>> square( 9 )

81

>>> square( (3+5j) ) # Fonctionne également avec un nombre complexe, des

fractions, matrices, etc.

(0.90704544951604504-0.70300197182731272j)



Tout fichier source contenant du code Python est désigné comme étant un « module ». Le langage inclut le concept des « namespaces » qui compartimente le contexte des objets tels que les variables, instances de classes ainsi que les fonctions. Ainsi, un fichier source Python, qu’il implémente un script (approche similaire à du Bash/Perl), une classe (approche similaire à Java), une collection de fonctions (librairie, tel qu'on pourrait le voir en C), des paramètres de configuration (similairement à un fichier INI ou YAML) est un module compartimenté par la logique des namespaces propre au langage et facilitant sa réutilisation sans pour autant nécessiter l’adoption d’un quelconque paradigme de programmation ou de travail additionnel. Cette utilisation des namespaces se différencie de l’utilisation qui en est faite en C++ où son utilisation est facultative et n’est pas forcément compartimentée par chacun des fichiers sources, classes, etc.

La librairie standard de Python est souvent citée comme l’un de ses principaux avantages. Il y a en effet un grand nombre de modules qui sont livrés avec l’interpréteur. L’expression anglaise souvent employée « batteries included » vise à illustrer l’idée qu’une installation Python est relativement complète et auto-suffisante. Citons les exemples suivants parmi les modules de la librairie standard :

Gestion de communications interprocessus (asynchrones, ssl, RPC, HTTP).

Gestion de collections (ensembles).

Persistance et sérialisation des données.

Débogueur intégré avec outils de profilage.

Outils de développement d’IHM.

Expressions régulières, compression, services de cryptographie, etc.

Les librairies disponibles pour les programmeurs, ainsi que la documentation complète qui y est associée, accélèrent le développement d’applications et facilitent le partage de code. Lequel sera inévitablement plus concis et compréhensible vu l’universalité de la librairie standard.

La console Python est un outil fréquemment utilisé d’une manière analogue à CSH ou BASH. C’est-à-dire que de nombreux développeurs exécutent et développent leurs programmes directement à l’intérieur d’une console, contrairement à Perl ou tout autre langage compilé où des programmes seraient lancés suivant l’édition. Cette approche d’interaction directe avec un programme en exécution, propre à Python, facilite le débogage ainsi que certaines approches exploratoires comme l’introspection d’objets ou l’interaction avec les données. Une telle approche est compatible avec les exigences de la recherche. Nous verrons plus loin des environnements de travail qui facilitent d’avantage cette approche exploratoire.

L’interpréteur a été porté sur toutes les grandes plateformes (Windows, OSX, UNIX, Android, etc.) et le code produit par le programmeur est habituellement distribué en code source (approche typique du logiciel libre) ou en bytecode, de manière analogue aux fichiers .class de Java qui sont exécutés sur une machine virtuelle propre au langage.



3. OUTILS D’INTÉGRATION ET D’EXTENSION

L’implémentation principale de l’interpréteur est en C et s’appuie sur de nombreuses librairies systèmes en C. Pour cela, Python inclut dans sa librairie standard des routines facilitant l’encapsulation de code en C.

Par ailleurs, d’autres implémentations existent telles que Jython, qui est un interpréteur implémenté en Java, facilitant la réutilisation de classes « natives » Java ainsi que l’extension de programmes Java par une console Python. Citons également IronPython qui est une implémentation pour .NET. Citons aussi des implémentations JavaScript et des encapsulations Fortran, R, Matlab, parmi d’autres actuellement disponibles. Cython, quant à lui, permet de générer automatiquement des extensions en C compilées à partir de code Cython/Python offrant une bonne performance à peu de frais.

Le grand nombre d’implémentations et d’encapsulations inter-langages font que Python est souvent employé comme outil d’intégration pour faire le pont entre divers langages de programmation dans un seul et même processus. Cette approche a le potentiel de réduire le code d’intégration des types de données (réduction de code dit de type « boiler-plate ») et faciliter le transfert des données d’une fonction à une autre tout en ne nécessitant pas de mécanisme de sérialisation particulier. Aussi, le grand nombre d’environnements-cibles du langage maximise le champ d’action de compétences Python (c.-à-d. UNIX, WEB/JavaScript, calculs GPU, applications « desktop », etc.).

Toujours dans l’optique de l’intégration et dans le contexte du travail quotidien du chercheur, il importe de pouvoir aisément lancer des programmes en sous-processus et de filtrer les résultats produits par la sortie standard. En ce sens, Python offre, depuis la librairie standard, le module subprocess qui permet des appels systèmes simples ou plus sophistiqués afin d’interagir de manière synchrone ou asynchrone avec les entrées/sorties d’un programme en ligne de commande. Par exemple, si l’on voulait lancer un programme « process_directory » avec comme argument le chemin d’accès et arrêter l’exécution du programme Python dès qu’une erreur survenait au niveau du sous-processus, il suffirait de faire comme suit :

subprocess.check_call( [ 'process_directory', '/var/local/audio_files' ] )

L’exécution de ce programme se fera en tenant compte de la valeur de sortie du programme (code d’erreur) et, dans le cas d’une erreur, une exception dans le contexte du code Python sera générée permettant de retracer aisément le sous-processus fautif. C’est une approche robuste qui s’appuie sur le mécanisme d’exceptions intégré dans Python que l’on peut recommander en tant que bonne pratique. L’annexe propose d’autres approches d’appels système.

En ce qui concerne la syntaxe du langage, le code source Python est dépourvu de points-virgules ou autres marqueurs de « statements ». Ainsi, c’est l’indentation du code qui définit le contrôle de flux. L’utilisation d’une indentation syntaxiquement significative est perçue par bon nombre de débutants comme facteur intimidant et il y a effectivement une certaine fragilité associée à la mise en forme « syntaxique » du code à l’aide d’espaces et de tabulation. Cela rend la normalisation des standards de codage au sein d’une organisation d’autant plus impérative.



4. RÉVISION DE L’ÉCOSYSTÈME SCIENTIFIQUE DE PYTHON

Basées sur la librairie standard, un grand nombre de librairies en code source ouvert (open source) ont été développées ces dernières années et sont partagées sur des sites centralisés de partage de librairies Python tel que « Python Package index » (https://pypi.python.org/pypi). L’installation de celles-ci est facilitée par des programmes de découverte automatique de dépendances tels que les « easy_install », « pip » ou même des outils de séparation fonctionnelle de dépendances tels que « VirtualEnv ». On recense actuellement près de 30 000 librairies tiers parti sur le Python Package Index, touchant des domaines variés tels que la science, le traitement des langues naturelles, le développement Web, etc.

4.1 La pile Scipy

Pratiquement toutes les librairies de calcul numériques et scientifiques se basent sur un seul et même assemblage de librairies qui est désigné « Scipy stack » ou pile « Scipy ». Cette fondation comporte une librairie de calcul matriciel multidimensionnelle nommée Numpy et un grand nombre de routines numériques à caractères variés (statistiques, optimisation, intégration numérique, équations différentielles, traitement de signal, séries de Fourier, etc.) qui sont regroupées sous la librairie « Scipy ». Sont regroupés autour de ces deux librairies principales, des librairies telles que «matplotlib » pour la visualisation 2D et 3D, et PyTables pour l'interaction avec des fichiers HDF5 supportant les types de données matriciels proposés par Numpy. PyTables sera exploré dans un autre document. La librairie de calcul symbolique Sympy est également parfois considérée comme élément de la pile Scipy.

>>> import numpy as np

>>> np.idendity( 3 )

array([[ 1., 0., 0.],

[ 0., 1., 0.],

[ 0., 0., 1.]])

>>> a = np.arange(16)

>>> a

array([ 0, 1, 2, 3, 4, 5, 6, 7,

8, 9, 10, 11, 12, 13, 14, 15])

>>> b = a.reshape(2,2,2,2)

>>> b

array([[[[ 0, 1],

[ 2, 3]],

[[ 4, 5],

[ 6, 7]]],

[[[ 8, 9],

[10, 11]],

[[12, 13],

[14, 15]]]])

>>> b.ndim

4

>>> b.shape

(2,2,2,2)

>>> a = np.diag( np.arange(3) )

>>> a

array([[0, 0, 0],

[0, 1, 0],

[0, 0, 2]])

>>> a[1, 1]

1

>>> a[2, 1] = 10 # third line, second column

>>> a

array([[ 0, 0, 0],

[ 0, 1, 0],

[ 0, 10, 2]])

>>> a[1]

array([0, 1, 0])

Ci-dessus, exemples de manipulations de matrices Numpy.



4.2 Routines numériques optimisées

Le calcul matriciel effectué par Numpy n’est pas entièrement codé en Python. Numpy repose sur des routines d’algèbre linéaire optimisées que sont les librairies telles que BLAS. On recense actuellement près de 20 variations d’implémentations dont certaines sont commerciales et d’autres nées de projets en code source ouvert (open source). Une installation typique de Numpy offerte par une distribution Linux repose sur ATLAS, une variante automatiquement optimisée. Celle-ci n’est pas la plus rapide. Ce titre reviendrait à l’implémentation BLAS que procure la librairie de calcul MKL d’Intel. Toutefois, une récente variante en code source ouvert nommée OpenBLAS talonne la librairie d’Intel en termes de performance. La communauté de développeurs derrière OpenBLAS est active, laissant entrevoir, pour les prochaines années, une intéressante progression des performances sur les nouvelles architectures de processeurs1

Dans tous les cas, Numpy peut être configuré pour s’appuyer sur l’une ou l’autre de ces quatre implémentations de BLAS en fonction de son budget, son infrastructure, etc.

In [1]: l = range(1000)

In [2]: %timeit [i**2 for i in l]

10000 loops, best of 3: 126 us per loop

In [3]: a = numpy.arange(1000)

In [4]: %timeit a**2

100000 loops, best of 3: 2.85 us per loop

Ci-haut, une comparaison du temps de calcul d’une liste d’éléments sous Python et sous Numpy.

Ainsi, il est possible d’effectuer des opérations matricielles avec un bon niveau de performance tout en retenant l’interface de programmation haut niveau que proposent Numpy et Python. Il est également intéressant de mentionner l’existence de projets en code source ouvert visant à optimiser d’avantage la performance de Numpy tels que Numba. Dans certains cas, ce dernier peut accélérer le temps d’exécution par un facteur de 100 en employant divers processus d’optimisation tels que la compilation « just-in-time ».

4.3 Installation de la pile Scipy

L’installation des différents modules constituant la pile Scipy est à la portée de tous. Les modules nécessaires sont généralement offerts par les gestionnaires de paquetages des distributions Linux (ou via MacPorts pour Mac) où les versions employées sont souvent désuètes au vu de la fréquence élevée des mises à jour. Ainsi, il est généralement conseillé d’installer les modules via les programmes de gestion de

1 https://a248.e.akamai.net/camo.github.com/621d1fec9bf07835209187eacc927ea2c1d4377e/687474703a-2f2f7869616e79692e6769746875622e636f6d2f4f70656e424c41532f6467656d6d5f736e625f317468726561642e706e67.



dépendance de Python (pip, easy_install) plutôt que les versions offertes par Linux/MacPorts.

Par ailleurs, il existe des distributions logicielles rassemblant les modules de la pile. On peut citer les produits des entreprises Enthought (EPD et Canopy), Continuum Analytics (Anaconda). Ces entreprises offrent des services de support et de consultation de leur assemblage de la pile Scipy. Anaconda est disponible sous forme d’image AMI facilitant son déploiement sur EC2/OpenStack. Il existe aussi des distributions de code source ouvert telles que Python(x,y). Ces distributions sont particulièrement utiles pour les utilisateurs de Microsoft Windows ou, dans une moindre mesure, Mac OSX.

Citons finalement le projet SAGE qui rassemble tous les éléments de la pile Scipy pour en faire une application de calcul mathématique plus particulièrement adaptée au milieu de l’enseignement.

4.4 Comparaison avec MATLAB

Avec ces librairies de base fournies par la pile Scipy, une installation Python possède un environnement d'exécution de calcul numérique comparable à celui de MATLAB. À la différence de MATLAB, Octave ou R, un programme Scipy repose sur un langage de programmation généraliste complet au lieu d’un langage de script prévu pour l’exécution de routines dans un environnement clos. Ainsi, sous Numpy, la syntaxe sera plus verbeuse, mais aussi plus extensible.

Les performances de Numpy reposant sur MKL sont très similaires aux performances de MATLAB reposant sur MKL. Par exemple, pour une extraction des valeurs propres (eigenvalues) d’une matrice définie par la fonction Numpy suivante :

def test_eigenvalue():

i= 500

data = random((i,i))

result = numpy.linalg.eig(data)

avec un équivalent MATLAB tel que :

disp('Eig');tic;data=rand(500,500);eig(data);toc;

on obtient des résultats de comparaison de performance tels que :

Fonction Numpy / MKL/

Xeon8core / MKL MATLAB / MKL/

Xeon8core-R2008a

Facteur d’accélération

Numpy

test_eigenvalue 772ms 986ms 1,28

Source : http://dpinte.wordpress.com/2010/03/16/numpymkl-vs-matlab-performance/



Tout comme pour MATLAB, il existe, en plus des fonctions scientifiques et mathématiques incluses dans Scipy, des toolkits ou trousses d’outils regroupant des modules à vocation plus pointue. Ces trousses d’outils sont généralement classées par un préfixe de contexte « SciKit ». Il existe des trousses pour le Machine Learning, pour le traitement de l’audio, etc. Elles peuvent être installées avec les outils d’installation avec gestion de dépendances tel que mentionné précédemment.

4.5 IPython comme environnement d’expérimentation

Une approche habituelle dans le cycle de programmation en Python est d’inclure la console interactive dans les tâches du développeur. C’est-à-dire qu’au lieu d’employer le cycle « édition-compilation-test », on retrouvera souvent le cycle « exploration-édition » où l’édition du code source est souvent effectuée selon une approche quasi documentaire, c.-à-d. qu’on officialise le code qui « fonctionne » dans un fichier texte après avoir expérimenté l’utilisation de ses fonctions. Selon cette approche et dans le but de renchérir les fonctionnalités de la console de base, le projet IPython a été créé. À la base, IPython est donc essentiellement une console Python « de luxe » permettant l’exploration et l’exécution de code avec de nombreuses fonctionnalités additionnelles. Parmi ces nouvelles fonctionnalités, IPython offre le profilage en ligne du code, des fonctions de chronométrage, un historique interactif des commandes et des résultats. Son adoption a été très large et très rapide. On retrouve une console IPython dans une grande partie des IDE (Environnement de Développement Intégré) tels que VisualStudio. Le financement de son développement a été appuyé par des initiatives telles que le U.S. Department of Defence High Performance Computing Program. IPython est un projet assez jeune, mais sa popularité fait en sorte qu’il est souvent au cœur de toute solution de calcul numérique en Python, au même titre que la pile SciPy. On prévoit la version 1.0 pour juillet 2013.

IPython offre une console Python enrichie sous trois formes différentes. L’une d’entre elles est particulièrement attrayante pour quiconque effectue un travail exploratoire. Il s’agit d’une interface Web nommée « notebook ».

Depuis celle-ci, il est possible de faire l’édition du code arbitrairement groupé sous formes de cellules, exécuter ces cellules et ajouter de la documentation en ligne avec mise en forme enrichie. La mise en forme possible inclut tout ce qu’un navigateur sait interpréter, c.-à-d. HTML, HTML5, Flash, JavaScript, etc., et permet la rétroaction entre ces éléments et le code développé. Le texte est mis en forme par le langage Markdown et permet l’édition en ligne de formules mathématiques en format Latex. En contraste avec un script traditionnel, le groupage de codes en cellules permet de séparer de manière agile des blocs fonctionnels pouvant être relancés au besoin selon l’exploration effectuée. Le résultat de ces cellules est archivé dans le même document et facilite ainsi la traçabilité des expériences tout en permettant la réutilisation des résultats.

Il est possible de sauvegarder une session d’édition en tant que fichier et ce dernier est un fichier texte humainement lisible en format JSON, permettant de versionner la session par un système comme SVN, Git ou Mercurial. Cela permet d’effectuer un suivi des expériences et des résultats. On peut même inclure la référence à la version dans la production des résultats, de manière à augmenter la traçabilité des données et des expériences. Certains chercheurs utilisent un lien HTTP vers une copie publique de leur



session IPython notebook dans leurs articles scientifiques afin d’appuyer la reproductibilité des expériences. Par ailleurs, il est possible d’exporter le code exécutable dans un fichier épuré de la mise en forme IPython vers un module Python standard, si tel était le besoin.

Bien que l’on accède à cette interface Web par un navigateur, il est possible de lancer l’interface localement sur son ordinateur, car le noyau IPython possède un serveur HTTP intégré, basé sur Tornado.

Le tout offre une interface qui s’apparente quelque peu à celle de Mathematica ou Maple et offre au chercheur la possibilité d’effectuer de la visualisation interactive des données ainsi que de la documentation enrichie en même temps que la programmation et l’exécution de manière centralisée.

Finalement, rappelons que, tout comme pour la console IPython de base, il est possible pour la console notebook d’agir à titre d’interface frontale pour les calculs distribués effectués sur un cluster IPython. Bien que les deux solutions puissent être employées de manière indépendante, leur très bonne intégration rehausse leur utilité mutuelle. Le rassemblement de ces fonctionnalités rend le calcul exploratoire par une solution IPython potentiellement très attrayante pour le chercheur.

Ci-haut, un exemple de session notebook d’IPython illustrant les possibilités d'employer la mise en forme d’équations mathématiques à l’aide de Latex, ainsi que la mise en forme et l’insertion en ligne d’illustrations.



5. CONCLUSION

Par la création de conférences spécialisées sur des domaines précis du métier, la communauté en code source ouvert Python a su se rassembler afin de contribuer de manière concertée pour faire avancer certains projets clés. Citons le rassemblement des projets Python Numeric et Python Numarray pour former Numpy en 2005. Ou encore l’unification de PyTables avec Numpy qui formera semblablement la prochaine génération de solution de calcul en Python (Blaze). Les projets sont en constante mutation et même si cela peut causer des maux de têtes aux administrateurs logiciels des équipes de recherche, on peut aussi conclure que l’intérêt des développeurs de ces logiciels est décidément d’offrir des solutions innovantes et adaptées aux cas posés par la recherche scientifique. Il existe de nombreuses solutions logicielles qui sont en utilisation et qui ont semblablement contribué au succès de projets de recherche importants. Citons l’utilisation de Python dans de grands projets de recherche tels que le grand collisionneur de Hadrons du CERN2.

En somme, il s’agit d’un choix technologique pertinent pour une équipe de recherche et la polyvalence de la technologie peut être perçue comme étant garante du succès de son adoption.

2 http://archive.euroscipy.org/talk/2051.



GLOSSAIRE

SaaS

Software as a service : Approche consistant à offrir une solution logicielle non pas en tant que logiciel pouvant être installé par le client et géré par une licence d’exploitation, mais plutôt par une facturation à l’utilisation du service selon une entente préétablie.

Typage

Procédé par lequel un langage de programmation détermine les types de données des variables (entiers, caractères, etc.).

INI

Format de fichier de configuration popularisé par Microsoft devenu plutôt désuet de par ses limitations, mais toujours employé à cause de sa simplicité.

YAML

Yet Another Markup Language : Format de fichier usuellement employé pour définir des configurations avec des types de données plus complexes que INI et qui permet d’être aisément édité par l’humain tout en demeurant facilement traité par un programme.

AMI

Amazon Machine Image : Image d’un système d’exploitation complet pour être mis en exécution sur l’infrastructure d’infonuagique d’Amazon.

EC2

Elastic Cloud Compute : Infrastructure d’infonuagique d’Amazon.



ANNEXE

Raccourcis utiles

La console IPython, sous ses trois formes, offre des raccourcis qui facilitent d’avantage le prototypage rapide. Ceux-ci sont appelés « magic commands » et sont souvent précédés du signe « % ». Par exemple, « %px » qui lance l’exécution d’un statement IPython sur tous les nœuds enregistrés dans une perspective client sur un ipcluster, ou %prun et %timeit, qui permettent de profiler du code en ligne. Ces commandes sont propres à IPython et pourront être employées dans des scripts, mais il faut demeurer conscient qu’un interpréteur Python de base ne connaîtra pas la signification syntaxique de ceux-ci. Mentionnons quelques autres raccourcis particulièrement utiles :

%debug

Lorsque le code exécuté génère une exception, ce raccourci permet d’entrer en mode debug en initialisant une console dans le contexte de l’exception au dernier niveau de la pile d’appels (stacktrace). Il devient alors aisé de naviguer dans la pile d’appels (et leur contexte) avec les commandes « up » et « down », et d’interagir avec les variables et les fonctions. Exceptionnellement, dans la dernière version 0.13, cette commande n’est pas disponible pour le mode « notebook ». On fera par exemple :

In [35]: def div(a,b) :

....: return a/b

....:

In [36]: div(43, 0)

---------------------------------------------------------------------------

ZeroDivisionError Traceback (most recent call last)

<ipython-input-36-2b5233bf5745> in <module>()

----> 1 div(43, 0)

<ipython-input-35-366953835411> in div(a, b)

1 def div(a,b) :

----> 2 return a/b

ZeroDivisionError: integer division or modulo by zero

In [37]: %debug

> <ipython-input-35-366953835411>(2)div()

0 return a/b

ipdb> print b

0



%edit

Cette fonction permet de coupler l’édition depuis la console interactive à un fichier pour édition. On l’utilise fréquemment de pair avec la fonction %hist qui affiche l’historique des commandes dans la console. Il s’agit d’une fonction utile seulement dans les modes de console autres que le « notebook ». Avec celle-ci, il devient possible de développer ses idées dans la console et lorsqu’on cherche à les officialiser, on peut faire une commande telle que :

%edit 12-17 23-45

Cela aura pour effet d’ouvrir le programme d’édition de texte par défaut pour l’édition des lignes d’entrée 12 à 17 et 23 à 45 depuis l’historique de la session. Typiquement, il faudra faire un peu de mise en forme (refactoring) des fonctions développées et commandes soumises afin d’en faire un module fonctionnel.

!

Ce raccourci permet de lancer n’importe quelle fonction depuis la ligne de commande. Son utilité particulière tient dans la possibilité de récupérer les sorties de la commande en tant qu’objet Ipython.SList dans le namespace Python. L’objet résultant permet de récupérer l’information sous plusieurs formes telles que liste plate, chaîne de caractères, etc., c.-à-d. :

In [38]: cd /var/

/var

In [39]: a = ! ls

In [40]: a

Out[40]:

['backups',

'cache',

...

'tmp']

Couplé à la commande « %px » dans le contexte de l’exploitation d’un cluster, il devient aisé de lancer des commandes systèmes sur plusieurs machines et de récupérer leur sortie de manière synchrone.



?

Ce raccourci permet d’obtenir de la documentation en ligne pour un objet considéré, c.-à-d. :

In [41]: import os

In [42]: os?

Type: module

String Form:<module 'os' from '/usr/lib/python2.7/os.pyc'>

File: /usr/lib/python2.7/os.py

Docstring:

OS routines for Mac, NT, or Posix depending on what system we're on.

This exports:

- all functions from posix, nt, os2, or ce, e.g. unlink, stat, etc.

- os.path is one of the modules posixpath, or ntpath

- os.name is 'posix', 'nt', 'os2', 'ce' or 'riscos'

...

Documents

veille Osterrath Rapport de veille Mai 2013 - ofti.org · et statiquement typés tels que le C/C++ ne se prêtent pas toujours aussi bien aux ... Le typage dynamique offre des avantages