Python, le serpent très dynamique

1. Des objets dynamiques

1.1 Des propriétés dynamiques

Dans une grande majorité de langages dits « objets », il est indispensable de définir toutes les propriétés d'une classe lors de sa définition. Prenons un exemple en C++, avec une classe basique Voiture, qui possède quelques champs qui ont leur nom et leur type bien définis.

Une fois la compilation passée, tout va bien, on a notre numéro de plaque comme on s'y attend :

En Python, ce code va devenir :

Et là encore, le résultat sera atteint :

Jusque-là, on ne voit pas trop l'intérêt de Python, à part des ; et des {} en moins. Là où il devient intéressant repose sur le fait que le développeur peut ajouter, vérifier ou enlever n'importe qu'elle propriété d'un objet, non pas dans la définition de la classe ou dans la fonction d'initialisation de l'instance (méthode __init__), mais n'importe où dans le code.

Notre exemple peut se transformer en une forme simplifiée :

Nous avons seulement déclaré Voiture comme une classe vide et là encore, le résultat est le même :

Le C++ ne sera pas capable d'une telle chose. Sans déclaration préalable d'un champ, la phase de compilation ne va tout simplement pas aboutir :

Bien entendu, l'abus de cette fonctionnalité en Python peut vite déboucher sur du code illisible et inmaintenable. Si les différents utilisateurs de la classe ne se mettent pas d'accord sur les propriétés qu'elle définit, le code n'a aucune chance de fonctionner. Ainsi, elle n'est à utiliser que dans des cas restreints, comme quand un attribut n'est utile que temporairement. Elle ne doit pas devenir la norme.

1.2 La propriété __dict__

Il est important de voir qu'un attribut ainsi ajouté n'est pas commun à toutes les instances de la classe Voiture.

La sanction est immédiate :

En fait, l'explication est simple : les objets en Python possèdent de base une propriété nommée __dict__, qui est un dictionnaire regroupant l'ensemble des attributs de l'objet :

donne :

On obtient d'ailleurs le même résultat en remplaçant :

par :

Ceci montre bien que __dict__ représente le point d'accès vers les propriétés des objets.

1.3 Exemple de création de propriété

Si l’ajout d'un attribut peut sembler anecdotique, il est pourtant utile dans certains cas. Ici, nous allons prendre une classe qui représente un nœud d'un graphe. Cette classe expose uniquement deux propriétés :

- un identifiant ;

- une liste des nœuds fils.

Nous avons une boucle dans notre graphe et définissons une fonction permettant de la détecter. Ici, elle devra identifier un problème. Elle réalise un simple parcours en profondeur et a besoin de savoir si elle est déjà passée sur un nœud ou non. On peut bien sûr utiliser un tableau global à la fonction, mais ce n'est pas très élégant, ni très pratique dans le cadre d'un parcours de graphe qui se prête plus naturellement à des algorithmes récursifs. Nous pouvons plutôt ajouter un attribut deja_vu aux nœuds permettant de savoir si nous l'avons déjà parcouru ou non.

Elle détecte bien notre boucle :

L’ajout à chaud d'une propriété a évité de la définir dans l'initialisation des nœuds et de l'alourdir inutilement.

1.4 La suppression d'une propriété

Mais nous avons dans notre exemple deux problèmes de nature bien différente :

- Il faudrait faire une boucle sur la vérification has_loop pour tous les nœuds en réinitialisant deja_vu si nous ne sommes pas sûrs de partir de la racine de l'arbre.

- Nous avons laissé traîner une propriété dans nos objets qui n'est plus utile par la suite.

Le premier problème sera laissé en exercice aux lecteurs. Le second peut se résoudre très facilement en Python : la suppression d'un attribut est aussi simple que sa création. Il suffit d'appeler le mot-clé del :

donne bien ce que l'on attend de la suppression d'une propriété :

Les développeurs n'ont ainsi plus d'excuse pour laisser des attributs inutiles traîner dans leurs objets.

1.5 Gestion uniforme de l'accès aux propriétés

La méthode d'accès aux propriétés directement par __dict__ est pratique, mais nous verrons un peu plus tard dans la partie sur l'optimisation mémoire que cet accès direct n'est pas valable pour tous les objets. Il est préférable d'utiliser des fonctions du langage qui permettent de gérer toutes ces possibilités en un seul appel.

Elles sont au nombre de quatre :

- getattr : obtenir la valeur d'une propriété ;

- setattr : changer sa valeur ;

- hasattr : savoir si l'objet la possède ;

- delattr : la supprimer.

Ces fonctions sont très simples d'utilisation :

On obtient :

Un avantage de cet accès est utile également lorsque le nom des propriétés n'est pas connu lors de l'écriture du code. Lorsque l'on écrit del titine.plaque, il n'est pas possible de ne définir plaque qu'à l'exécution, alors qu'avec l'écriture delattr(titine, variable), il est possible de donner la valeur que l'on souhaite à variable. Nous allons voir un exemple de cela par la suite.

2. Le data driven programming

2.1 L'art d'être feignant

Avant cela, j'aimerai introduire la technique suivante par une toute petite incartade personnelle : je me souviendrai probablement toute ma vie d'une phrase prononcée par un de mes professeurs : « un bon informaticien est un informaticien feignant ». Plus j'y pense, et plus je trouve qu'il a parfaitement raison. Outre le fait qu'il est agréable dans ces conditions de chercher à « être bon », on peut voir dans « bon informaticien » une personne à la recherche de l'efficacité (à opposer à une personne à la recherche de la perfection, qui est contraire à l'efficacité) et dans « feignant », une automatisation des opérations répétitives, ce qui est au final l'essence même de l'informatique. Cette automatisation va permettre d'enlever des opérations manuelles qui sont sources d'erreurs, et va améliorer l'efficacité globale du système.

La technique que nous allons voir ici est l'illustration même de ce principe : on va enlever des opérations manuelles pour le développeur afin de diminuer sa charge et le risque d'erreur par la même occasion. Le fait qu'il ait moins de travail va lui permettre de se concentrer sur les actions à fortes valeurs ajoutées, comme travailler sur l'architecture ou optimiser des algorithmes trop consommateurs.

2.2 Moins de code, (normalement) moins d'erreurs

Cette technique se nomme data driven programming. Elle consiste à ne plus coder « en dur » les opérations que l'on fait sur les propriétés d'un objet, mais de lire ces opérations d'un tableau. Typiquement, ce dernier sera un dictionnaire dont les clés sont les noms des attributs sur lesquels nous allons opérer, et les valeurs sont les opérations à effectuer, typiquement une fonction.

Voici un exemple sur le même code avec et sans la technique. Imaginons ici que nous créons les objets Voitures avec des valeurs lues d'un fichier plat, donc de simples chaînes de caractères. Nous souhaitons changer les champs qui en ont besoin en vraies valeurs :

On la change maintenant par une nouvelle version. Le tableau operation liste nos actions à effectuer sur les attributs des voitures :

Et on demande l'affichage :

On obtient :

Comme toute technique, elle a ses avantages et ses inconvénients. Dans sa forme actuelle, il n'est pas évident de voir son avantage, car l’ajout d'un argument n'est pas plus simple dans le tableau qu'explicitement dans une ligne de code et obscurcit légèrement le code. Nous allons voir par la suite qu'elle peut se révéler très efficace.

2.3 Complétons le tableau des opérations

Si le gain précédent n'est pas suffisant avec une seule opération, qu'à cela ne tienne, ajoutons-en. Il est rare de n'avoir qu'une opération à faire sur ses objets. Plaçons-nous dans un cas simple : nous souhaitons toujours lire la configuration d'objets depuis un fichier texte. Ces objets possèdent de nombreuses propriétés, certaines étant obligatoires, d'autres non. Étant lues comme des chaînes de caractères, il est nécessaire de les transformer en « objets Python » comme des entiers ou des flottants, comme précédemment. Pour finir, certaines de nos propriétés étant optionnelles, il est important de définir pour celles-ci des valeurs par défaut. De cette manière, une fois lus et gérés, nos objets seront complets, prêts à servir l'application.

Vu que nous avons plusieurs opérations, il serait possible d'utiliser plusieurs dictionnaires. Il est cependant bien plus efficace (entendre « feignant » ici) de n'en utiliser qu'un seul pour toutes.

Un exemple de tableau d'opérations sera le suivant :

On obtient alors les objets suivants :

L'avantage de l'utilisation du data driven sur ces traitements réside dans le nombre des attributs et d'opérations gérés de cette manière. Là où avec la méthode manuelle, le développeur avait besoin de l'ordre de O(P*Op) lignes (P étant le nombre de propriétés, Op le nombre d'opérations), ici, c'est de l'ordre de O(P + Op). Si pour notre petit exemple le gain est moyen, pour des objets un peu conséquents, le gain se compte rapidement en centaines de lignes.

Un autre avantage concerne également la localisation des informations sur les attributs. Si un développeur souhaitait en changer un avec la méthode « normale », comme un simple changement de nom, il lui faudrait parcourir le code et changer toutes ses occurrences. Avec cette nouvelle méthode, ils sont tous regroupés en un seul endroit, le tableau des opérations. Le code écrit est, lui, indépendant du nom des propriétés. Le développeur n'a besoin que de changer une occurrence pour que tout son code soit changé.

Cette méthode revient en fait à définir des propriétés à nos attributs : celle-ci est obligatoire et est entière, celle-ci est optionnelle et vaut par défaut 1, etc.

2.4 L'ADN des objets

Nous voyons que finalement, toute l'intelligence de cette méthode réside dans ce tableau d'opérations. Si l'objet était une cellule, ce tableau serait l'ADN, car il définit comment se créent et se comportent nos objets. L'ADN se trouve dans le noyau de nos cellules, mais où placer notre tableau ?

Ce tableau n'est pas spécifique à une instance d'objet, mais bien à toute sa classe. C'est donc dans celle-ci qu'il faut le placer. Cet emplacement est tout bénéfique :

- Il évite des duplications du tableau pour chaque instance.

- Il sera utile en cas d'héritage de classe, chacune ayant son propre ADN.

Mais un problème se pose cependant : comment accéder depuis une instance à cette information stockée dans sa classe ?

Python propose une solution très simple à ce problème : l'instance peut accéder à sa classe grâce à la propriété __class__. La classe sera vue comme un simple objet, comme n'importe quel autre en Python, et ceci concerne également toute la partie dynamique d’ajout de propriétés, comme nous le verrons par la suite.

Pour l'instant, revenons à notre classe Voiture. Sa nouvelle définition devient :

En cas d’ajout de propriétés à Voiture, il suffit de modifier le tableau adn et elle sera gérée comme il faut par le reste du code. La fainéantise (comprendre « efficacité ») à l'état brut.

2.5 ADN et héritage

Cette méthode devient encore plus efficace lorsque le développeur l'utilise pour plusieurs classes. Imaginons de nouvelles classes nommées Conducteur, Entrepôt, et Assurance. Il peut être intéressant de définir une classe mère nommée Item, qui propose la méthode default_and_complete et dont les autres héritent. De cette manière, pour intégrer, vérifier et transformer chaque classe, il suffira de lui définir son tableau adn. Lorsque l'instance va appeler la fonction, elle va rechercher le tableau self.__class__ qui sera bien celui de sa propre classe. Multiplier les classes va permettre de gagner encore en complexité de code, passant de O(C*P*Op) lignes (C étant le nombre de classes) à O(C*P + Op).

Une telle définition peut être :

A titre d'exemple, cette technique a été utilisée dans le projet Shinken, réimplémentation en Python de Nagios (daemon en C). Dans Nagios, il est possible de définir des objets de manière partielle et le nombre de propriétés des objets est couramment supérieur à 50. Là où la partie de code de Nagios de la création des objets fait environ 15000 lignes, celle de Shinken en fait moins de 900 grâce à l'utilisation massive de cette technique.

3. L'impact de cette dynamicité et sa gestion

3.1 Une consommation mémoire accrue

Nous avons vu une partie de la puissance de la dynamicité de Python. Les miracles et l'informatique n'étant pas faits pour s'entendre, ces techniques ont un coût non négligeable sur les ressources consommées par les applications. Le CPU est impacté, car là où l'accès à une structure est en 0(1) en C ou C++, elle est bien plus consommatrice dans les langages dynamiques. Cependant, la ressource la plus touchée est indéniablement la mémoire. S'il est bien un point soulevé par les administrateurs systèmes lorsqu'ils doivent gérer une application faite dans un langage interprété, c'est le fait qu'ils vont devoir commander beaucoup de barrettes pour leurs serveurs.

Voyons un peu ce qu'il en est dans les faits avec Python. Comme nous l'avons vu, il stocke pour chaque instance un dictionnaire __dict__ avec des chaînes de caractères pour le nom des propriétés et leur valeur. Imaginons une classe Personne qui possède quelques propriétés :

Si on en crée 100000, nous arrivons à une consommation globale de 60 Mo. Si cette valeur est intéressante, elle n'aide pas à déterminer ce que l'on doit optimiser. C'est pour cela que nous allons utiliser le module guppy, disponible sur le site pypi.org et s'installant simplement :

L'utilisation de guppy est fort simple :

Nous obtenons le détail de la consommation mémoire :

On remarque que sur les 60 Mo consommés par l'application, 51 Mo le sont par les dictionnaires des personnes. Il est vrai que stocker 100000 fois les chaînes nom, prenom, age, etc., est assez consommateur.

3.2 Les __slots__ au secours

Les langages compilés classiques n'ont pas ce problème, car l'accès à une propriété se fait toujours avec le même décalage d'adresse par rapport au début de l'objet. Ils n'ont pas besoin de garder le nom des attributs. Une fonctionnalité de Python permet d'imiter ce fonctionnement, tout en conservant les propriétés dynamiques des objets. Son utilisation est fort simple : il suffit de déclarer les champs que nous souhaitons utiliser dans un tuple nommé __slot__ situé dans la classe. Une restriction cependant : cette dernière doit être une « new style class », qui se dit d'une classe qui hérite de la classe object et qui ne change pas grand chose dans la grande majorité des cas par rapport à une classe normale. L'aspect « nouveau » de ces classes ne doit pas effrayer : elles étaient nouvelles pour la version 2.2 de Python, qui date tout de même de 2003...

__slots__ va en fait prendre la place de __dict__ et ne conserver qu'une seule fois les chaînes de caractères des noms des propriétés pour toutes les instances de la classe.

Voici une utilisation de __slots__ avec notre classe Personne :

Et le résultat de la consommation fournie par guppy :

La consommation globale est passée de 60 Mo à un peu moins de 10. Ceci s'explique simplement : le principal consommateur, qui était dict of __main__.Personne, n'est plus présent. Le gain est substantiel, mais n'avons-nous pas sacrifié des possibilités du langage pour quelques Mo de mémoire gagnés ?

Tentons d’ajouter un attribut qui n'a pas été déclaré dans __slots__ :

Le verdict est sans merci :

Horreur et damnation, les __slots__ dans leur forme actuelle empêchent l’ajout à chaud d'attributs. Comme nous l'avons vu, __slots__ remplace __dict__, et c'est lui qui offrait l'aspect dynamique du langage. Heureusement, la solution à ce problème est toute simple : il suffit d’ajouter __dict__ dans le tuple __slots__ pour retrouver nos fonctionnalités manquantes :

donne bien :

On voit bien que l’ajout de propriété est accepté, de même que l'appel hasattr. Cet appel, avec ses confrères getattr, setattr et delattr, s'occupe de rechercher l'information au bon endroit, sans avoir à se soucier si l'attribut est déclaré ou non dans __slots__.

3.3 Les __slots__ et la sérialisation

Un autre souci se pose avec la sérialisation d'objets qui utilisent __slots__. La sérialisation permet de transformer les objets en format plus ou moins binaire pour les échanger entre machines, ou tout simplement les sauvegarder dans des fichiers plats. Le module dédié à cela se nomme cPickle. Son utilisation est fort simple :

Mais que se passe-t-il si l'on souhaite sérialiser un objet utilisant __slots__ ? Dans une situation normale, la sérialisation s'occupe du __dict__ pour sauvegarder/relire l'objet. Mais avec __slots__, la description de l'objet se trouve dans sa classe, et ceci n'est pas « sauvegardable » dans un fichier. L'appel dump sur l'objet Personne va échouer :

Python demande qu'une méthode __getstate__ soit définie. Ce sera à elle de renvoyer un dictionnaire, ou plus généralement un objet, comprenant les propriétés que souhaite exporter le développeur. De même, une méthode __setstate__ sera nécessaire pour regénérer l'objet à partir du dictionnaire sauvegardé.

Nous pouvons ajouter les méthodes suivantes à la classe Personne :

Les objets Personne peuvent ensuite être sérialisés sans problème :

On obtient :

Dans notre exemple, nous avons codé getstate à la main. Il peut être utile ici d'appliquer « l'art du bon informaticien » et utiliser un tableau adn pour sauvegarder ou non certaines propriétés.

4. Les metaclass : une classe en crée une autre

4.1 Intérêt et création d'une metaclass

En Python, nous avons vu que les classes sont des objets comme les autres. Qui dit objet dit instanciation. Lors de celle-ci, il est courant de modifier les valeurs des objets. Mais que ceci implique-t-il pour les classes ? Comment pouvons-nous changer ses caractéristiques lors de leur création ? C’est justement le rôle des metaclass. C’est une classe qui va contrôler la création d’une autre.

Sa définition est relativement simple : elle hérite de la classe type et implémente la méthode __new__, qui contrôle la création des classes. Cette méthode prend en paramètre :

- cls : pointeur vers la metaclass qui implémente __new__ ;

- name : nom de la classe créée ;

- bases : liste des classes dont hérite la classe ;

- attrs : liste des attributs déjà connus de la classe.

C'est principalement sur ce dernier argument que nous allons pouvoir influer. Du point de vue de la classe générée, il suffit de faire appel à la metaclass par l’ajout de la propriété __metaclass__ dans sa définition.

4.2 Exemple d'utilisation d'une metaclass

Notre premier exemple de metaclass est très simple : il va se limiter à lister les attributs de la classe générée.

Ceci donne au lancement de l'application :

4.3 Générer __slots__ automatiquement

Si notre précédent exemple permet de visualiser le fonctionnement d'une metaclass, il n'est pas des plus utiles dans la vie d'un développeur. Nous allons chercher encore une fois à être efficace grâce à cette technique. Nous avons vu précédemment l'intérêt de __slots__. Un de ses défauts était qu'il fallait le remplir à la main avec toutes les propriétés qui devaient composer notre objet. C'est fastidieux, et il y a fort à parier qu'au bout d'un moment, le développeur oubliera lors d'un ajout de nouveaux attributs de les y ajouter. L'impact sera uniquement sur la mémoire, il y a donc de fortes chances qu'il passe totalement inaperçu.

Nous allons utiliser une metaclass pour générer automatiquement __slots__. Elle va avoir besoin de la liste des propriétés de la classe, et ceci tombe bien, c'est justement le rôle de notre cher tableau adn.

On obtient bien :

5. Les decorators

5.1 Quand le développeur se change en décorateur

Nous avons vu que les classes et leurs instances étaient des objets comme les autres. Une autre famille d'objets au point de vue conceptuel l'est également réellement en Python : les fonctions. Tout comme pour les classes avec les metaclass, nous allons pouvoir contrôler la création et l'exécution des fonctions. Les fonctions possèdent des propriétés comme __doc__, __init__ ou __call__. Ce sont ces deux dernières qui vont nous intéresser ici : __init__ est appelée à la définition de la fonction, __call__ lorsqu'elle est exécutée. Nous pouvons envelopper, ou décorer en terme pythonique, ces appels avec d'autres fonctions.

C'est le rôle des decorators. Ce sont des classes qui vont pouvoir « s'appliquer » sur les fonctions, comme une classe qui hérite d'une autre. La classe décoratrice n'a besoin que de définir elle-même les méthodes __init__ ou __call__, suivant si elle veut modifier la création de la fonction ou son exécution. Il suffit d'appeler le decorator avec le signe @ juste avant la déclaration d'une fonction pour qu'il soit appliqué. Il est possible d'avoir plusieurs decorators sur une fonction, un par ligne. Ils seront tous appelés les uns à la suite des autres.

5.2 Exemple de decorator : memoized

Prenons un exemple classique pour les decorators : memoized. C'est un decorator qui va ajouter à la fonction une propriété cache où vont être stockés tous les résultats des appels de la fonction. Lors de ces appels justement, si les arguments ont déjà été appelés, plutôt que de rééxécuter la fonction, le decorator va renvoyer la valeur mise précédemment en cache.

Cette méthode de cache est sûrement l'une des plus efficaces pour qui veut optimiser la consommation CPU au prix d'une augmentation de sa consommation mémoire.

On obtient :

Sans @memoized, on obtiendrait :

Plus une fonction est appelée souvent et avec des arguments similaires, plus cette méthode est efficace. Nous voyons ici que sa mise en place est très facile, et qu'une ligne suffit désormais au développeur pour ajouter un système de cache à une fonction qui n'en avait pas. De plus, celle-ci peut se concentrer sur son rôle (ici, calculer la suite de Fibonacci) et non gérer elle-même un cache pour un problème de performance. Les decorators sont la base du développement orienté aspect, qui consiste à découpler les différents aspects d'un programme (aspect métier, aspect log, etc.).

6. La puissance derrière les écailles du serpent

Nous n'avons fait que soulever quelques facilités apportées par la dynamicité de Python, de nombreuses autres restent encore à explorer, comme les décorateurs de classes ou les properties. Ce langage permet aux développeurs de laisser libre cours à leur imagination. Bien utilisées, ces techniques avancées peuvent faciliter la vie des programmeurs, leur permettant de se concentrer sur des tâches plus importantes que le simple remplissage de fichiers de codes sources, comme l'écriture des tests de non-régressions, ou les réunions d'architectures devant la machine à café.