Le design pattern strategy, qui consiste à déléguer une partie du comportement d’un objet à un autre objet, est probablement l’un des motifs de conception les plus utiles en programmation. Trop souvent les gens utilisent l’héritage là où la composition serait plus adaptée, et une injection de dépendance bien faite permet de gagner beaucoup en qualité de code.

Si vous ne vous souvenez plus de ce qu’est le pattern strategy, vous pouvez faire un saut sur le chapitre qui en parle dans le guide de la POO :)

Mais comme un petit rappel ne fait pas de mal, en très court, strategy ressemble à ça :

class MonObjet:
    def __init__(self):
        self.strategie = MaStrategie()

    def foo(self):
        return self.strategie.foo()

Ce qui permet à une sous-classe de changer la strategy ou non :

class MonSousObjet(MonObjet):
   def __init__(self):
        self.strategie = MonAutreStrategie()

Ou de changer la strat dynamiquement :

hop = MonObjet()

hop.stategie = SuperNewStrat()

Mais si vous vous en tenez à ce design, les utilisateurs de la classe vont très vite rencontrer des limitations.

D’abord, une bonne stratégie peut avoir besoin de contexte. Dans ce cas, donnez lui le choix d’avoir une référence à l’objet parent:

class MonObjet:
    def __init__(self):
        # Passer self permet à la stratégie de connaître son contexte. 
        # Le désavantage est l'introduction potentiel d'un couplage entre 
        # les deux objets, et potentiellement des effets de bords supplémentaires. Cela reste 
        # néanmoins souvent une bonne idée.
        self.strategie = MaStrategie(self)   
    ...

Ensuite, une stratégie devrait pouvoir être passée à la création de l’objet :

class MonObjet:
    def __init__(self, strategie=MaStrategie):
        # On donne la priorité à l'objet passé en paramètre. Si il n'y en a 
        # pas on crée la stratégie par défaut.
        self.strategie = strategie(self)  
    ...

Cela permet d’overrider la stratégie pour les usages plus avancés, tout en permettant aux débutants de ne pas se soucier de cela car il existe quand même une valeur par défaut.

truc = MonObjet(UneStrategieDifferente)

Comme le travail dans un init est souvent assez redondant, avoir un endroit pour permettre aux sous-classes de facilement overrider la stratégie est une bonne pratique. En Python il est courant d’utiliser les variables de classes pour cela :

class MonObjet:

    # On appelle souvent cet attribut "strategy_class" ou "strategy_factory"
    strategie_par_default = MaStrategie

    def __init__(self, strategie=None):
        self.strategie = strategie(self) if strategie else self.strategie_par_default(self) 
    ...

class MonSousObjet(MonObjet):
    # Et boom, overriding de la stratégie par la classe enfant en une ligne.
    # Django fait ça par exemple avec les classes based views et l'attribut 
    # model
    strategie_par_default = MonAutreStrategie

Une fois que vous avez fait tout ça, vous avez déjà fait mieux que 90% des programmeurs. Néanmoins si vous voulez vraiment mettre la petit touche pro à votre API, vous pouvez aussi permettre la création dynamique de la stratégie:

class MonObjet:

    strategie_par_default = MaStrategie

    def __init__(self, strategie=None):
        self.strategie = strategie(self) if strategie else self.build_strategy() 
    
    def build_strategy(self):
        return self.strategie_par_default(self)

    ...

Wow, ça en fait des self et des factories :) En fait, ça fait la même chose qu’avant, c’est à dire que le tout premier exemple de code tout simple qu’on a vu en début d’article marche toujours ! C’est la beauté de la chose.

La différence, c’est que maintenant une classe enfant peut overrider build_strategy() et créer des stratégies à la volée, en fonction du contexte d’exécution. Par exemple créer une stratégie différente en fonction d’une valeur de base de données. C’est rare que ça arrive, et c’est vraiment de l’usage avancé. Mais quand vous avez ça, vous êtes certains que votre code est prêt à être utilisé par autrui. Car si cet autrui n’est pas content, il peut faire une profonde coloscopie à votre code et y insérer ce qu’il veut, quand il veut.

Être dev après tout, c’est être un peu poète.

Cette convention est tellement bien établie que les outils de génération de documentation et de complétion de code la prennent souvent en compte.

Ca fait partie de la philosophie du langage : tout est ouvert. Guido parle même d’open kimono, le petit coquin.

Pourtant il existe une fonctionnalité qui semble rendre un attribut privé, qui est d’utiliser un préfix de DEUX underscores :

class Yo(object):
    def __init__(self):
        self.__bitch = True
>>> Yo().__bitch
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
 in ()
----> 1 Yo().__bitch

AttributeError: 'Yo' object has no attribute '__bitch'

En fait, l’attribut n’a pas été rendu privé, mais son mécanisme de résolution de nom a été changé :

>>> Yo()._Yo__bitch
    True

C’est ce qu’on appelle le name mangling, et cette obscure fonctionnalité a été utilisée pour s’assurer qu’un attribut ne sera pas écrasé par erreur par une classe enfant.

L’attribut n’est pas privé, il est juste accessible autrement, c’est tout.

• Récupérer et afficher une ou plusieurs entrées en base de données.
• Afficher et valider un formulaire.
• Faire un mix des deux pour modifier des entrées en base.

Je ne les ai jamais aimées. Avant, les vues génériques étaient sous forme de fonction, simples, pratiques, c’était parfait. Et ça a été retiré du framework pour des versions OO sous prétexte que c’était plus flexible.

Maintenant, ce sont ces gros tas immondes, avec un ordre d’appel de méthodes complexes, des mixins dans tous les sens et une chaine d’héritage velue.

Je pense que c’est une bonne occasion pour rappeler que la POO n’est pas faite pour être utilisée partout, tout le temps. Aucun putain de paradigme de programmation n’est fait pour être utilisé partout, tout le temps. C’est pour ça qu’il y en a plusieurs.

Dans notre cas des CBV, la conséquence est que c’est un enfer pour expliquer tout usage qui ne soit pas un hello world, ce que la doc se garde bien de faire.

Après il y a toujours un malin pour dire “mais si tu vois tu fais ça, et ça, ça prend 5 lignes, c’est pas si dur”. Ouai, maintenant va expliquer ça à un stagiaire, et donne lui un exercice avec une form view qui doit modifier un objet, le lier à un user seulement si il a la permission de le faire. Juste pour voir en combien de temps il trouve. Je vais en WE à Barcelone en attendant. Je prévoie une extension à Rome pour quand il devra relire son code le trimestre prochain.

Et si encore c’était pour un gain de productivité évident, je fermerais les yeux. Mais c’est pas le cas. Même moi qui sait utiliser ces… ces choses… je dois regarder dans la doc à chaque fois que j’en utilise une. Et ensuite quand je relis mon code quelques mois plus tard, je chope de pattes d’oies aux coins des yeux.

If you have to refer to the documentation every time you use a module, find (or build) a new module.

Dixit Kenneth Reitz, le mec qui a pondu requests. Donc on va user something else que les CBV, si vous le voulez bien.

Un lecteur m’a (encore) pointé du doigt qu’un schéma du MRO et de l’ordre d’appel des méthodes serait utile. Vous vous rendez compte du truc ? On peut comprendre l’ORM sans schéma alors que c’est une machine de guerre, et il faut une carte pour comprendre comment faire un listing un peu custo avec une CBV ? J’ai évalué la somme de travail pour faire ledit schéma, et elle est énorme : trop de classes, trop de méthodes, trop de subtilités.

Bref, je jette le tablier, fuck les CBV. Je ne les inclurai plus dans mes formations, mes tutos, mes aides sur les forums, etc.

Quand on veut une variable à usage interne, la convention est de la nommer avec un underscore devant :

class Monique:
    def __init__(self):
        self._private = "lessons"

Ça n’empêche rien, mais les devs savent qu’il faut éviter d’utiliser cette variable car elle ne fait pas partie de l’API publique de la classe, et l’implémentation pourrait changer plus tard.

Comme self, c’est une convention forte puisque la plupart des libs de completion du code la prennent en compte.

Il existe une fonctionalité moins connue, qui fait que quand on utilise deux underscores, accéder directement à la variable lève un AttributeError:

class Monique:
    def __init__(self):
        self.__private = "lessons"

m = Monique()
print(m.__private)
AttributeError: 'Monique' object has no attribute '__private'

Du coup, quelques rares personnes ont utilisé cette feature pour émuler des attributs privés, ignorant le fait qu’on vous dit partout sur la toile que tout est accessible en Python.

C’est une mauvaise idée.

C’est une mauvaise idée car si votre objectif est la sécurité, ça ne sert à rien puisque votre variable est accessible de tas de manières détournées différentes. Par exemple :

print(m.__dict__['_Monique__private'])
# lessons
m.__dict__['_Monique__private'] = None
print(m.__dict__['_Monique__private'])
# None

C’est une mauvaise idée car si votre objectif est de créer une API publique, un seul underscore suffit.

Enfin c’est une mauvaise idée car si vous fournissez une lib qui ne correspond pas à un besoin, quelqu’un peut toujours contourner le problème en monkey patchant votre code le temps que vous trouviez une solution plus propre. En rendant la variable “privée”, vous rendez ceci plus difficile, sans le rendre impossible. Tout le monde y perd.

Ceci dit pour la culture G, je me suis dit que ça pourrait intéresser quelques geeks de savoir comment lister les enfants d’une classe, récursivement.

def subclasses(cls, _found=()):
    """ Retourne toutes les classes héritant d'une classe """

    # On check que la classe est hérite bien de "object".
    # Utile uniquement pour un code 2.x qui utiliserait
    # des old style classes, qui n'ont pas "__subclasses__".
    if not isinstance(cls, type):
      raise TypeError('subclasses works only with new-style classes'
                            ', not %s' % cls)

    # On va stocker les classes rencontrées dans un set
    # pour éviter les doublons car on peut tomber sur
    # un héritage en forme de diamant.
    _found = _found or set()

    try:
      subs = cls.__subclasses__()
    except TypeError:  # Erreur levée si cls == type, petits vicieux
      subs = cls.__subclasses__(cls)

    for sub in subs:
        if sub not in _found:
            _found.add(sub)
            # Un appel récursif comme on les aimes
            subclasses(sub, _found)

    return _found

Pas très compliqué, donc, si on connait les piègeounets : ça ne marche pas sur les old syle classes, et il y a un traitement spécial pour type. Celà dit, qui utilise encore des old styles classes ? Et franchement lister les héritiers de type, à par pour satisfaire sa curiosité…

Aller, juste pour le fun, sur un virtualenv vierge:

for x in subclasses(object):
    print x
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 
## 

Putain, ça c’est du remplissage ! 20minutes serait fier de moi.

Vous trouvez qu’il y a beaucoup de fautes sur le blog ? Imaginez si ils n’étaient pas là !

Comme le notre, leur boulot est 100% bénévole, et croyez-moi quand je vous dis que ça bouffe du temps.

Foxmask et Kontre sont les plus actifs, donc j’aimerais les remercier particulièrement.

Mais il y a aussi ceux qui font ça en comment, et Réchèr vient tout juste de terminer un travail de malade sur la relecture le l’INTEGRALITE (8 parties super longues) du dossier sur la POO.

Gloire aux relecteurs !

(Et vive le fromage)

Car quand vous allez publier du code, un script, une lib voire, Dieu ait pitié de vous, un framework, les gens qui vont les utiliser vont avoir des besoins auxquels vous n’aviez pas pensé. Or, ils ne voudront pas modifier votre code. L’interêt d’utiliser le code d’un autre, c’est justement de s’éviter la maintenance. Ils voudront aussi prendre en main rapidement votre outil pour faire des choses simples sans avoir à tout comprendre.

Ainsi, il va vous falloir intégrer divers moyens d’étendre les fonctionnalités de votre code, afin que les autres dev puissent l’utiliser dans le cadre de leurs besoins.

Nous allons donc construire un projet bidon : une barre de progression en ASCII dont la sortie va ressembler à ceci :

Starting [========================================= ] 93%

L’idée est de pouvoir l’utiliser ainsi :

    with ProgressBar() as pb:
        for progres in faire_un_truc():
            pb.progress = progres

Nous allons le proposer ce projet sous forme de classe importable, et nous allons voir plusieurs manières de rendre ce code facile à prendre en main, configurable et extensible :

• Paramètres, avec un ordre intelligent et des valeurs par défaut saines.
• Templating de l’ouput.
• Methodes pouvant être écrasée par héritage.
• Getter and setter (ici via des propriétés)
• Exposition intelligente des attributs de la classe.
• Callbacks et passage réfléchi de paramètres à ceux-ci.

J’aurais pu ajouter l’injection de dépendance, mais j’ai déjà traité ce sujet dans un autre article, et je ne voulais pas charger celui-ci. Il est déjà bien gras.

J’ai aussi volontairement omis la docstring et les comments. Écrire une bonne doc est un article à part entière.

Pré-requis : être parfaitement à l’aise avec le POO et les références, comprendre le principe des context managers, avoir pigé les callbacks.

Et roulez jeunesse !

# -*- coding: utf-8 -*-



import sys

from io import IOBase


# On hérite d'IOBase pour permettre le détournement de stdout. Voir plus bas.
class ProgressBar(IOBase):


    # On met les paramètres par ordre de fréquence d'utilisation. Il est
    # plus probable que les programmeurs changent le total que la sortie
    # du programme.
    # Mettre des valeurs par défaut saines permet à l'utilisateur de faire
    # des essais sans trop regarder la doc. Par ailleurs, des valeurs par
    # défaut servent de documentation en soit, et apparaitront si help()
    # est appelé.
    def __init__(self, total=100,  percent_per_sign=1,
                 progress_sign='=', callbacks=(),
                 template='Starting [{bar}] {progress}%',
                 output=sys.stdout, intercept_stdout=True):

        # Par défaut le total est 100, afin que l'utilisateur passe un
        # pourcentage, ce qui est le plus naturel. Néanmoins, si il souhaite
        # s'affranchir de calculs, on lui permet de passer une autre valeur
        # qui sera ramenée à un pourcentage automatiquement à l'affichage
        # de toute façon.
        self.total = total

        # Customisation de base : changer le symbole de progrès. Par défaut
        # un égal, mais certains aiment les ., les - ou autre.
        self.progress_sign = progress_sign

        # Idem, si la personne veut une barre plus ou moins longue.
        self.percent_per_sign = percent_per_sign

        # la longueur de la barre de progression
        self.bar_len = 100 / percent_per_sign * len(progress_sign)

        # Le formatage de la progress bar se fait à l'aide d'une chaîne
        # ordinaire qui sert de template (avec le langage de formatage de Python)
        # et peut facilement être changée pour obtenir plus de contrôle
        # sur l'aspect de la bar.
        self.template = template

        # On peut aussi passer un tuple de fonctions qui permettent de réagir
        # à chaque fois que le progrès change. On utilise nous-même notre
        # système de callback pour que la methode print_progress() soit
        # appelée à chaque fois, mettant à jour l'affichage de la bar.
        self.callbacks = callbacks + (self.print_progress,)

        # Initialisation de 3 variables à vide. 'buffer' va contenir
        # tout ce qui va être écrit avec write() pour éviter de perturber
        # l'affichage de la bar, et '_progress' va contenir le progrès, mais
        # le '_' signale que c'est une variable à usage interne. Nous allons
        # en effet l'enrober dans une propriété. Enfin cursor_shift est
        # le nombre de caractères à effacer pour redessiner la bar à chaque
        # mise à jour.
        self.buffer = ''
        self._progress = 0
        self.cursor_shift = 0

        # Par défaut, on s'attend à ce que l'utilisateur affiche cette
        # bar directement dans le terminal, sur la sortie standard. Mais
        # il peut vouloir déporter l'affichage ailleurs (par exemple stderr).
        # Pour cette raison, on permet de passer le stream sur lequel
        # l'utilisateur va écrire, même si par défaut on prend sys.stdout,
        # donc la sortie standard.
        # Si l'utilisateur ne souhaite rien de tout cela, il peut également
        # retirer 'self.print_progress' de la liste des callbacks puisque
        # l'attribut est public.
        self.out = output

        # Comme on utilise la sortie standard par défaut, la barre peut
        # facilement être cassée par un autre code écrivant aussi sur la sortie
        # standard. Puisqu'un débutant ne comprendra pas rour se suite ce qui se
        # passe, par défaut on va intercepter stdout et mettre tout ce qui est
        # écrit dessus dans un buffer. Si jamais il y a des prints fait durant
        # l'affichage, il seront cachés, et stockés. Ce comportement n'est pas
        # forcément désirable, et peut donc être désactivé par un paramètre pour
        # l'utilisateur qui sait ce qu'il fait notamment dans le cadre
        # d'utilisation des threads.
        self._intercept_stdout = intercept_stdout and self.out == sys.stdout
        if self._intercept_stdout:
            # L'interception de la sortie standard se fait en remplaçant
            # sys.stdout par soi-même. C'est pour cette raison que ProgressBar
            # hérite de IOBase. En effet, de cette manière, on possède
            # l'interface d'un objet stream et tout écriture sur 'self' semblera
            # fonctionner comme sur sys.stdout. Cela permet de faire des prints
            # ou de lancer un shell et d'utiliser la barre, bien que
            # dans un shell cela monopolisera le prompt.
            sys.stdout = self


    # Afficher la barre à la création de l'objet retire de la flexibilité à
    # l'utilisateur qui peut vouloir le créer d'un côté, le stocker, et
    # démarrer l'affichage plus tard. L'affichage est donc conditionné
    # par cette méthode.
    def show(self):
        bar = self.format()
        self.out.write(bar)
        self.cursor_shift = len(bar)
        return self

    # Comme le plus souvent on voudra tout de même afficher la barre juste après
    # la création, on transforme cette classe en context manager. Pour cela on
    # créer un alias de la method show() qu'on appelle __enter__, puisque tout
    # objet qui a une méthode nommée __enter__ peut être utilisé comme context
    # manager. Si vous ne vous souvenez pas de ce que c'est, il y a un article
    # sur le blog à ce sujet. Mais en résumé, ce sont les objets utilisables
    # avec "with".
    # Notez qu'on ne fait pas __enter__ = show, ce qui serait un moyen plus
    # court d'aliaser, car il empêcherait __enter__ d'appeler le bon show()
    # en cas d'héritage, si show() est écrasé.
    def __enter__(self):
        return self.show()


    # Une petit méthode de nettoyage, qui ici va simplement remettre sys.stdout
    # à sa place.
    def stop(self, *args, **kwargs):
        if self._intercept_stdout:
            sys.stdout = self.out

    # Même topo, on alias stop en __exit__ pour avoir la sortie du context
    # manager. On a pas appelé directement ces méthodes __enter__ et __exit__
    # car l'utilisateur peut vouloir les appeler manuellement.
    def __exit__(self, *args, **kwargs):
        return self.stop()


    # Une simple propriété qui donne accès au progres en lecture...
    @property
    def progress(self):
        return self._progress


    # ... et en écriture. La différence étant qu'à l'écriture, on vérifie
    # que la valeur est bien comprise entre 0 et le total. On appelle aussi
    # les callbacks, et donc l'affichage se mettra à jour.
    @progress.setter
    def progress(self, value):

        if not 0 <= value <= self.total:
            raise ValueError("'value' is %s and should be set between 0 "
                             "and 'total' (%s)" % (value, self.total))

        # On le fait avant car les callbacks doivent être appelés
        # avec un état propre.
        previous_progress = self._progress
        self._progress = value

        # Ce que l'on va passer en paramètres aux callbacks est un choix
        # important. Déjà en premier paramètre, on passe self. Ainsi le callback
        # aura accès à presque tout, et on est certain qu'il ne se trouvera
        # pas dépourvu d'informations. Ensuite on passe le progrès. Normalement
        # il peut le récupérer à travers self.progress, mais comme on sait
        # que c'est une information très utilisée, on la passe par politesse,
        # pour faciliter la vie de l'utilisateur. Enfin, une information qu'il
        # ne pourrait pas avoir autrement est le progrès précédent. Bien que
        # nous ne l'utilisons pas dans notre callback, on peut imaginer que
        # c'est le genre d'info qui peut être utile, et qui ne peut être trouvée
        # dans self.
        for callback in self.callbacks:
            callback(self, self._progress, previous_progress)

        # Si on arrive au bout, on appelle stop() automatiquement. Stop()
        # étant idempotente, ce n'est pas grave si elle est appelée plusieurs
        # fois.
        if value == self.total:
            self.stop()

    # Un cas intéressant : pourquoi on ne fait pas self.template directement au
    # lieu de créer une property à vide ? Tout simplement parce qu'un template
    # est typiquement quelque chose que quelqu'un peut vouloir créer
    # dynamiquement (par exemple pour y ajouter une notion de temps qui passe).
    # Donc, on propose de passer le template en paramètre  dans __init__ car la
    # plupart du temps, c'est juste ce qu'on voudra faire : un simple changement
    # cosmétique statique. Mais afin de permettre plus d'extensibilité, on en
    # fait une propriété, qui, comme toute méthode, peut être écrasée avec de
    # l'héritage et permettrait à l'utilisateur de vraiment personnaliser son
    # affichage de manière poussée.
    @property
    def template(self):
        return self._template

    @template.setter
    def template(self, value):
        self._template = value

    # C'est cette méthode qui est appelée si on a détourné sys.stdout quand
    # l'utilisateur va faire un print. Elle doit s'appeler write(), car c'est
    # l'interface connue des objets stream. Grosso modo, on va juste
    # tout stocker dans une variable plutôt que d'afficher quoique ce soit
    def write(self, value):
        self.buffer += value

    # Pour une progrès donné, retourne la barre de progrès sous forme de
    # string ASCII. Elle est mise à part car elle peut ainsi être facilement
    # utilisée dans un callback.
    def format(self, progress=0):
        progress = progress * 100 / self.total
        bar = progress / self.percent_per_sign * self.progress_sign
        bar += (self.bar_len - len(bar)) * ' '
        return self.template.format(bar=bar, progress=progress)


    # Notre callback que l'on utilise pour afficher la barre. C'est une méthode
    # statique car cela nous permet de nous mettre dans les conditions exacte
    # d'un callback d'un utilisateur, qui ne sera qu'une fonction, sans self.
    @staticmethod
    def print_progress(progress_bar, progress, previous_progress):
        # '\b' permet de reculer le curseur dans le terminal, ce qui va
        # nous permettre de réécrire par dessus l'ancienne bar, et la mettre
        # à jour. Si vous tenez à faire un display multi ligne, sachez que '\b'
        # ne permet pas de reculer sur un saut de ligne, pour ça il faut
        # utiliser '\033[1A'
        progress_bar.out.write(progress_bar.cursor_shift * '\b')
        bar = progress_bar.format(progress)
        progress_bar.out.write(bar)
        # flush est nécessaire pour vider le buffer et obtenir un affichage
        # immédiat quand on écrit en direct sur un stream.
        progress_bar.out.flush()
        # on met à jour l'avancement du curseur, qui nous permettra de reculer
        # d'autant au prochain print_progress()
        progress_bar.cursor_shift = len(bar)



if __name__ == "__main__":

    # voici une utilisation standard de la barre :

    import time

    total = 1000
    # L'utilisation du context manager permet de ne pas se soucier d'appeler
    # show() ou stop() et autre détails d'implémentation.
    # On note aussi qu'avoir des valeurs par défaut pour l'initialisation de la
    # barre la rend très facile à utiliser sans trop se prendre la tête, et
    # ce malgré un code derrière assez complexe. On aurait même pu se passer
    # de "total".
    with ProgressBar(total) as pb:

        for i in range(total):
            time.sleep(0.001)
            # on voir l'interêt d'utiliser une property ici, ça rend la mise
            # à jour du progrès très simple
            pb.progress = i
            if i == total / 2:
                print("\nHalf the work already !")
                half = True
            if i == total * 0.7:
                print("Almost done")
                almost = True

        pb.progress = total

    # On peut afficher tout ce qui a été printé durant la progression de la
    # barre si besoin.
    print(pb.buffer)

    from datetime import datetime

    # Et une utilisation custo où on compte les secondes depuis le départ
    # et on les affiches dans le template

    class MaProgressBar(ProgressBar):

        def show(self):
            self.start = datetime.now()
            return super(MaProgressBar, self).show()

        # Comme on a template en tant que méthode, on peut l'overrider et
        # obtenir un comportement
        @property
        def template(self):
            seconds = (datetime.now() - self.start).seconds
            return '{bar} (running for %s seconds)' % seconds

        @template.setter
        def template(self, value):
            pass

    # Notre système de callback va se trouver utile :
    # on met un callback de plus qui va écrire dans un fichier (mais
    # il pourrait faire n'importe quoi, envoyer un post sur un site Web,
    # un mail, formatter le disque...)
    def update_progress(progress_bar, progress, previous_progress):
        with open('/tmp/progress.log', 'w') as log:
            log.write(str(progress))

    # On change aussi le signe de progrès pour quelque chose de plus pro
    pb = MaProgressBar(progress_sign=':-) ', percent_per_sign=10,
                       callbacks=(update_progress,))

    # Au besoin, on peut passer à l'affichage en manuel.
    pb.show()

    for i in range(100):
        time.sleep(.1)
        pb.progress = i

    pb.progress = 100

    pb.stop()

Télécharger le code de l'article

Vous connaissez mon manque d’attrait pour ça, on va donc clarifier.

Pour comprendre cet article, il vous faut les pré-requis suivants :

• Être à l’aise avec avec la programmation orientée objet : héritage, property…
• Bien comprendre la notion de référence.
• Avoir un peu de temps devant soi.

Et pour une fois, on va mettre un morceau qui colle bien au blog :

S’il vous plait, dessine moi un objet proxy

Un proxy, en anglais, c’est un mandataire, c’est à dire grosso merdo un intermédiaire. Un objet proxy est donc tout simplement un objet qui fait l’intermédiaire, généralement entre un objet et un autre.

Exemple, on a des enseignants qui vont avoir besoin d’une autorisation de sortie pour des enfants dans leur classe. Un enfant ne peut pas décider de cela, ses parents décident de ce genre de chose :

class Enseignant(object):

    # la demande d'autorisation attend un objet enfant en paramètre
    def demande_autorisation_de_sortie(self, enfant):
        return enfant.peut_sortir()


class Enfant(object):

    def __init__(self, age):
        self.age = age

    # mais un enfant ne peut pas donner cette information
    def peut_sortir(self):
        raise NotImplementedError('Un enfant ne peut decider de cela')


class Parent(object):

    # le parent va faire proxy sur l'objet enfant
    def __init__(self, enfant):
        self.enfant = enfant

    # et propose la même méthode que l'objet enfant afin de pouvoir
    # être passé en paramètre à sa place à la méthode
    # demande_autorisation_de_sortie()
    def peut_sortir(self):
        return self.enfant.age > 10

Ici, si la classe Enseignant appelle directement la méthode peut_sortir() de la classe Enfant, on obtient une erreur. :

>>> prof = Enseignant()
>>> enfant = Enfant(11)
>>> prof.demande_autorisation_de_sortie(enfant)
Traceback (most recent call last):
  File "", line 1, in 
    prof.demande_autorisation_de_sortie(enfant)
  File "", line 4, in demande_autorisation_de_sortie
    return enfant.peut_sortir()
  File "", line 13, in peut_sortir
    raise NotImplementedError('Un enfant ne peut decider de cela')
NotImplementedError: Un enfant ne peut decider de cela

Nous avons créé un système où on est obligé de créer une instance de Parent, qui va se placer entre la classe Enseignant et la classe Enfant, et qui va retourner la valeur pour cette méthode :

>>> parent = Parent(enfant) # on passe l'enfant en paramètre au parent
>>> prof.demande_autorisation_de_sortie(parent) # et le parent remplace l'enfant
True

Ceci est un objet proxy, c’est à dire un objet qui se place entre deux objets, et fait l’intermédiaire. Pour que cela marche, il faut que l’objet proxy, ici l’instance de Parent, ait la même interface (les mêmes méthodes, avec les mêmes paramètres et noms) que l’objet derrière le proxy, ici l’instance de Enfant.

Dans notre cas, c’est académique, ça ne sert pas à grand chose. Mais il y a des tas de cas utiles pour les objets proxy.

Ainsi, on veut parfois créer des objets dit “lazy”, littéralement “paresseux”, c’est à dire pas évalués tout de suite. C’est ce que fait Django dans le cadre de certaines chaînes de caractères traduites. En effet, en Django, il existe une fonction lazy_gettex() que l’on peut appliquer sur les chaînes à traduire. Mais elle ne retourne pas une string, car on ne connait pas encore la langue dans laquelle il faut traduire la chaîne : la langue dépend de l’utilisateur qui viendra demander la page Web en question. lazy_gettex() retourne un objet proxy, et quand, à l’appel de la page Web, on tente de manipuler cet objet comme une string pour l’afficher, le proxy va chercher la traduction, et retourne la bonne chaîne. Pour que ça marche, il faut que l’interface de l’objet lazy ressemble trait pour trait à celui d’une chaîne.

Dans d’autres cas on veut mettre un proxy pour gérer des permissions, et selon le niveau de permission, l’objet proxy donne accès ou non à l’objet derrière lui.

Le design pattern décorateur, le fameux @truc en Python, n’est jamais qu’un objet fonction qui fait proxy vers une autre fonction qu’on a enrobé.

Mais la raison majeur pour laquelle on va utiliser un objet proxy est le design pattern “adapter”.

Ce n’est pas un chapeau, c’est un boa qui a avalé un éléphant

En informatique, on aime bien les traitements généralistes.

Par exemple, imaginez cet objet qui dit si on a le droit de se bourrer la gueule :

class Videur(object):

    def tu_peux_rentrer(self, personne):
        """
            Cette fonction n'est pas réaliste, puisque bien entendu une mineure
            à gros nichons rentrerait, et un arabe en short lacoste non,
            mais heureusement l'informatique est plus simple que notre société.
        """
        return personne.age >= 18

class Personne(object):
    def __init__(self, age):
        self.age = age

Et tant que vous avez la main sur le système, tout va bien dans le meilleur des mondes :

>>> import random
>>> clients = [Personne(random.randint(12, 65)) for x in xrange(random.randint(0, 100))]
>>> videur = Videur()
>>> for client in clients:
...     if videur.tu_peux_rentrer(client):
...         print("Glouglou")
...
Glouglou
Glouglou
Glouglou
Glouglou
Glouglou
...

Mais malheureusement la vie n’est pas toujours pleine de licornes et de bisounours, et votre collègue, lui, il a codé une lib en C qui a extrait les clients d’un XML, et quand vous vous mappez directement dessus avec ctype, vous obtenez des clients comme ça:

class Client(object):
    def __init__(self, majeur):
        self.majeur = majeur

Bon, vous vous dites que c’est pas grave. Après tout, c’est juste une condition à rajouter :

class Videur(object):

    def tu_peux_rentrer(self, personne):

        if hasattr(personne, 'age'):
            return personne.age >= 18

        return personne.majeur

Ouai mais votre commercial arrive avec un super contrat avec pillierdebar.com, et il faut s’interfacer avec leur API SOAP de 1997, dont la deserialisation vous retourne :

class Prospect(object):
    def __init__(self, datetime):
        self.date_de_naissance = datetime

Les connards. Ah les connards.

Mais bon, c’est pas grave, c’est juste une petite condition à rajouter.

import datetime

class Videur(object):

    def tu_peux_rentrer(self, personne):

        if hasattr(personne, 'age'):
            return personne.age >= 18

        if hasattr(personne, 'date_de_naissance'):
            # TODO: prendre en compte les années bisextiles
            return (datetime.datetime.now() - personne.date_de_naissance) / 365 > 18

        return personne.majeur

Bon, vous allez enfin pouvoir soufll…. Ahhhh ! Votre boss appelle, il a oublié de vous dire, le stagiaire travaille aussi sur une feature, et a fait son propre objet Prospect, c’est comme l’objet Client mais pas pareil. Non on ne peut pas changer. Oui il a fait de la merde mais si on change tout son code pête. Il se barre demain. Il n’a pas fait de test. Démerde toi.

class LeClient(object):
    def __init__(self, majeur_de_combien):
        self.__majeur_de_combien = majeur_de_combien

    def get_majeur_de_combien(self):
        return self.__majeur_de_combien

A ce stade là, le code est tellement moche de toute façon, vous vous en branlez complètement. Vous allez rentrer jouer Left4Dead avec un mod qui transforme les zombies pour qu’ils aient la tête de votre patron. Le reste n’est que détail d’implémentation.

class Videur(object):

    def tu_peux_rentrer(self, personne):

        if hasattr(personne, 'age'):
            return personne.age >= 18

        if hasattr(personne, 'date_de_naissance'):
            # TODO: prendre en compte les années bisextiles
            return (datetime.datetime.now() - personne.date_de_naissance) / 365 > 18

        if hasattr(personne, 'get_majeur_de_combien'):
            # retourne le nombre d'années après 18 ans ou -1. Don't ask...
            return personne.get_majeur_de_combien() > -1

        return personne.majeur

Quelque moi(s) plus tard, les specs changent. Il faut maintenant pouvoir vérifier la carte d’identité des clients. Ou la carte de membre. Et garder l’ancien système compatible bien entendu. Ah, et il y a aussi des controleurs, c’est comme des videurs, mais qui doivent vérifier si les personnes dans le bar sont majeurs, sauf qu’il n’acceptent pas la carte de membre ou la date de naissance donnée à l’oral.

class CarteDeMembre(object):
    pass


class CarteIdentité(object):
    def __init__(self, date_de_naissance):
        self.date_de_naissance = date_de_naissance


class Client(object):
    def __init__(self, majeur=None, carte_identite=None, carte_membre=None):
        self.majeur = majeur
        self.carte_identite = carte_identite
        self.carte_membre = None


class Videur(object):

    def tu_peux_rentrer(self, personne):

        if hasattr(personne, 'age') and personne.age is not None:
            return personne.age >= 18

        if hasattr(personne, 'carte_membre'):
            return True

        if hasattr(personne, 'carte_identite') and personne.carte_identite is not None:
            now = datetime.datetime.now()
            return (now - personne.carte_identite.date_de_naissance) / 365 > 18

        if hasattr(personne, 'date_de_naissance'):
            # TODO: prendre en compte les années bisextiles
            return (datetime.datetime.now() - personne.date_de_naissance) / 365 > 18

        if hasattr(personne, 'get_majeur_de_combien'):
            # retourne le nombre d'années après 18 ans ou -1. Don't ask...
            return personne.get_majeur_de_combien() > -1

        return personne.majeur


class Controleur(object):

    def est_autorise(self, personne):

        if hasattr(personne, 'age') and personne.age is not None:
            return personne.age >= 18

        if hasattr(personne, 'carte_identite') and personne.carte_identite is not None:
            now = datetime.datetime.now()
            return (now - personne.carte_identite.date_de_naissance) / 365 > 18

        if hasattr(personne, 'date_de_naissance'):
            # TODO: prendre en compte les années bisextiles
            return (datetime.datetime.now() - personne.date_de_naissance) / 365 > 18

        if hasattr(personne, 'get_majeur_de_combien'):
            # retourne le nombre d'années après 18 ans ou -1. Don't ask...
            return personne.get_majeur_de_combien() > -1

        return personne.majeur

Bon, là c’est la merde. Vous le sentez, demain il va y avoir un portail électronique qui check uniquement les cartes de membres. Quand il va falloir faire une modif quelque part, ça va être galère. La maintenance va être un enfer. Le debuggage, bien relou. Il faut trouver un moyen de faire plus propre.

C’est ici qu’entre en jeu le pattern “adapter”. Un adapter, c’est comme les adaptateurs pour prises, mais pour les objets. C’est un proxy qu’on met devant pour que la prise ressemble à une autre.

Dans le domaine du code, ça veut dire qu’on va enrober chaque objet dans un autre pour qu’ils aient tous la même interface. Le traitement du coup sera de nouveau très simple, et la complexité sera répartie dans les adapters.

# on met le code commun dans un parent abstrait, notamment le check pour
# savoir si un adapter convient a un objet donné
class Adapteur(object):

    cls = None

    def __init__(self, objet):
        self.objet = objet

    def peut_adapter(self, objet):
        return self.cls == type(objet)


# un adapter, c'est juste un objet proxy qui arrondit les angles
class PersonneAdapteur(Adapteur):

    cls = Personne

    # on va réduire la complexité en faisant en sorte que tous les checks
    # soient cachés derrière une simple property
    @property
    def majeur(self):
        return self.objet >= 18


class ProspectAdapteur(Adapteur):

    cls = Prospect

    @property
    def majeur(self):
        # TODO: prendre en compte les années bisextiles
        return (datetime.datetime.now() - self.objet.date_de_naissance) / 365 > 18


class LeClientAdapteur(Adapteur):

    cls = LeClient

    @property
    def majeur(self):
        # retourne le nombre d'années après 18 ans ou -1. Don't ask...
        return self.objet.get_majeur_de_combien() > -1


class ClientAdapteur(Adapteur):

    cls = Client

    def __init__(self, objet):
        self.objet = objet

    @property
    def majeur(self):

        if self.accepte_carte_membre and self.objet.carte_membre is not None:
            return True

        if self.objet.majeur:
            return True

        if self.object.carte_identite is not None:
            now = datetime.datetime.now()
            # TODO: prendre en compte les années bisextiles
            return (now - personne.carte_identite.date_de_naissance) / 365 > 18

        return False

Le contrôleur et le videur deviennent du coup beaucoup plus simples, maintenant que la logique est normalisée :

class VerificateurDeMajorite(object):
    def check_majorite(self, personne):
        for adapteur in self.adapteurs:
            if adapteur.peut_adapter(personne):
                return adapteur(personne).majeur

# du coup un vérificateur, c'est très déclaratif
class Videur(VerificateurDeMajorite):

    adapteurs = (
        PersonneAdapteur,
        ClientAdapteur,
        ProspectAdapteur,
        LeClientAdapteur,
    )

    def tu_peux_rentrer(self, personne):
        return self.check_majorite(personne)


class Controleur(VerificateurDeMajorite):

    adapteurs = (
        PersonneAdapteur,
        # ProspectAdapteur()
        LeClientAdapteur(),
    )

    def est_autorise(self, personne):
        return self.check_majorite(personne)

Si il faut ajouter un autre format de client, il suffit de coder un adapteur. Si il faut ajouter une autre classe de vérification, il suffit de lui donner les bons adapteurs.

Et le traitement est aussi simple, car si vous avez une liste qui contient plein de clients différents :

>>> clients = [Client(majeur=True), Client(carte_de_membre=CarteDeMembre()), Client(carte_identite=CarteIdentité(datetime.datetime.now()), LeClient(-1), Personne(age=16)...]

Vous pouvez quand même vérifier tout ça sans y réfléchir:

>>> videur = Videur()
>>> for client in clients:
...     if videur.tu_peux_rentrer(client):
...         print("Glouglou")
...
Glouglou
Glouglou
...

>>> controlleur = Controleur()
>>> for client in clients:
...     if not controlleur.est_autorise(client):
...         print("Ahhhh !")
...
Ahhhh !
Ahhhh !
...

Dans un cas comme celui de notre exemple, l’adapter est un peu overkill, on s’en tirerait aussi bien avec une liste de fonctions, et le code serait plus léger et lisible.

Mais quand les objets et la logique deviennent très complexes, tout ramener à une interface commune permet de simplifier énormément le code.

J’ai nommé…

Les métaclasses.

Comme tous les articles sur la question, je commence avec la citation standard :

Les métaclasses sont une magie trop obscure pour que 99% des utilisateurs s’en préoccupe. Si vous vous demandez si vous en avez besoin, ce n’est pas le cas (les gens qui en ont vraiment besoin le savent avec certitude et n’ont pas besoin d’explications sur la raison).

Tim Peters, les mec qui a écrit le PEP20.

En résumé, cet article ne vous servira probablement pas. Je me suis servi, en 10 ans, deux fois des métaclasses dans ma vie. C’est pour le sport, quoi.

Pré-requis:

• Avoir lu la partie précédente et bien tout compris. Mais alors bien tout. Si il subsiste un doute dans votre esprit, relisez toute la série car vous ne vous en sortirez pas.
• Notamment, avoir bien pigé le principe de object, car les metaclasses ne fonctionnent qu’avec les New Style classes.
• Comprendre le principe de références, callable, lambdas et dictionnaires en Python. En fait à peu prêt tout sauf les métaclasses parce que ce truc est ce que vous voulez apprendre en dernier de toute façon.
• Être bien reposé et avoir du temps devant soi. Pas la peine de lire en diagonal. Vraiment.

Musique.

Au début, il y avait les objets

Et Dieu Guido vit que cela était bon, et qu’il n’y avait pas de raison de ne pas se marrer un bon coup, alors il décida que les classes, qui servaient à fabriquer les objets, seraient aussi des objets.

Dans la plupart des langages, une classe est vraiment juste un plan pour produire un objet, un bout de code, une syntaxe élaborée pour dire “voici ma classe”. On peut l’imaginer comme cela en Python également, et vivre très heureux et avoir beaucoup de bons moments :

>>> class CreateurDObject(object):
...     pass
...
>>> mon_objet = CreateurDObject()
>>> print(mon_objet)
<__main__.CreateurDObject object at 0x1c22fd0>

Sauf qu’en Python, les classes sont aussi des objets.

Je vous laisse maturer ça 1 minute. Prenez une inspiration.

Quand l’interpréteur Python lit le mot class, il crée un objet. Dans le code ci-dessus, en mémoire, Python crée un objet CreateurDObject.

Cet objet est une classe, il permet de créer d’autres objets – ses instances – mais ça reste un objet. Et comme tous les objets…

On peut l’assigner à une variable :

>>> ReferenceACreateurDObjet = CreateurDObject
>>> ReferenceACreateurDObjet()
<__main__.CreateurDObject object at 0x1c320d0>

On peut le passer en paramètre :

>>> def afficher_une_class(cls):
...     print("Hey, on m'a passé la classe %s" % cls)
...
>>> afficher_une_class(CreateurDObject)
Hey, on m'a passé la classe 

On peut lui ajouter des attributs à la volée :

>>> CreateurDObject.nouvel_attribut = 'nouvelle valeur'
>>> hasattr(CreateurDObject, 'nouvel_attribut')
True
>>> CreateurDObject.nouvel_attribut
u'nouvelle valeur'

Le 7eme jour, on se faisait grave chier alors on a créé des classes dynamiquement

Peut être vous souvenez-vous qu’on peut créer des fonctions à la volée ?

Parce qu’on peut faire pareil avec les classes :

>>> def fabriquer_une_class(nom):
...     if nom == 'bulbizarre':
...         class Bulbizarre(object):
...             pass
...         return Bulbizarre # je retourne Bulbizarre, PAS Bulbizarre()
...     else:
...         class Salameche(object): # qui prenait carapuce, sérieux ?
...             pass
...         return Salameche
>>> Pokemon = fabriquer_une_class('autre')
>>> type(Pokemon) # Pokemon est une CLASSE, pas une instance

>>> nouveau_pokemon = Pokemon() # la je crée une instance
>>> type(nouveau_pokemon)

Une classe n’est pas quelque chose de figé dans le marbre, comme tout le reste en Python, on peut les fabriquer dynamiquement, les modifier en cours de route, les malmener, etc.

Aucun pokemon n’a cependant été blessé pendant la rédaction de cet article. Tiens je me demande si il y a des sites zoophiles spécialisés dans les Pokemons. Qu’est-ce que je raconte ? Évidement qu’il y en a. D’ailleurs Pikachu est comme une shocking flesh torch avec piles incluses quand on y pense. Ou un appareil à abdos. Il faut que je fasse des abdos, j’ai pris du bide. Heu… où j’en étais ?

Ah oui. Classes. Dynamiques.

Comme toutes les opérations courantes idées à la con, Python vous permet de faire ça complètement à la main. Maintenant vient la troisième Révélation Des Métaclasses : la fonction type() a deux usages.

Dans une première vie type() est une fonction ordinaire, elle sert à retourner le type d’un objet :

>>> print type(1)

>>> print type("1")

>>> print type(CreateurDObject)

>>> print type(CreateurDObject())

Et propose à sa logeuse de descendre ses poubelles. Mais elle a une autre vie électronique, elle est aussi capable de créer une classe.

Oui c’est très con d’avoir choisit la même PUTAIN DE FONCTION pour faire deux trucs qui n’ont rien à voir. Mais les deux usages ont un avenir et il va falloir faire avec, se caler ça où je pense et oublier votre avocat.

Bref, ça marche comme ça :

type(nom de la classe, tuple des parents de la classe, dictionnaire contenant les attributs)

Le nom de la classe, je pense que vous avez pigé.

Le tuple des parents, il peut être vide. C’est dans le cas où vous souhaitez un héritage : vous pouvez passer des références aux classes parentes.

Le dictionnaire est assez simple : chaque clé est un nom d’attribut, chaque valeur est une valeur d’attribut.

Exemple, cette classe :

>>> class Pokeball(object):
...     pass

Peut se créer ainsi :

>>> Pokeball = type('Pokeball', (), {})

Et s’utiliser tout pareil :

>>> print(Pokeball)

>>> print(Pokeball())
<__main__.Pokeball object at 0x1c32450>

Vous aurez noté que le nom de classe passé en paramètre est le même que celui de la variable qui va recevoir la classe ainsi créée. Oui, ils peuvent être différents. Non, ça ne sert à rien.

Et je sais que certains auraient préféré MyLittlePoney, mais je fais avec ma maigre culture G. Faudrait que je tente avec des noms de Pogs.

Un petit exemple avec des attributs :

>>> class Pokeball(object):
...     couleurs = ('rouge', 'blanc')

Ce qui donne :

>>> Pokeball = type('Pokeball', (), {'couleurs': ('rouge', 'blanc')})
>>> Pokeball.couleurs
(u'rouge', u'blanc')

Étant donné que les méthodes sont des attributs…

>>> class Pokeball(object):
  ...     def attraper(self):
  ...         print("ratééééééééééééé")
  ...       

Peut se traduire par :

>>> def out(): print "ratéééééééééééé"
...
>>> Pokeball = type('Pokeball', (), {'attraper': out})
>>> Pokeball().attraper()
ratéééééééééééé

Au passage, toute classe créée par type hérite automatiquement de object, pas besoin de le préciser.

Petite démo avec de l’héritage :

>>> class Masterball(Pokeball):
...     def attraper(self):
...         print("yeahhhhhhhhhh")
...         

Se transforme en :

>>> def out(): print "yeahhhhhhhhhh"
...
>>> Masterball = type('Masterball', (Pokeball,), {'attraper': out})
>>> Masterball().attraper()
yeahhhhhhhhhh

Je répète les Révélations Divines :

1. Les classes sont des objets.
2. On peut créer les classes à la volée.
3. type() permet de créer une classe manuellement.
4. Keanu Reeves est un mauvais acteur.

Vous voyez où je veux en venir, là, non ?

Et le tout puissant déclara : tu créeras des classes avec des classes

Et tu n’aimeras pas ça. Alors au début tu le feras avec des fonctions parce que c’est plus facile.

Une métaclasse, c’est seulement le nom du “truc” qui fabrique une classe. C’est tout.

C’est pour ça qu’on appelle cela des métaclasses, les classes des classes.

Puisque les classes sont des objets ?

Vous suivez ?

Non ?

Ah.

o

En deux lignes alors :

UneClasse = MetaClass()
un_objet = UneClasse()

Mieux ?

Vous avez vu la fonction type() créer des classes ? En fait la fonction type() est une métaclasse. C’est la métaclasse dont Python se sert pour créer tous les objets classes, quand vous tapez le keyword class.

Il est facile de voir ça en regardant l’attribut __class__, qui indique quelle classe a servi à créer un objet :

>>> pokemon_capture = 149
>>> pokemon_capture.__class__

>>> nom = 'magicarp'
>>> nom.__class__

>>> def attrapez_les_presque_tous(): pass
>>> attrapez_les_presque_tous.__class__

>>> class Pokedex(object): pass
>>> gadget = Pokedex()
>>> gadget.__class__

Mais quelle est le __class__ de tout __class__ ?

>>> attrapez_les_presque_tous.__class__.__class__

>>> pokemon_capture.__class__.__class__

>>> nom.__class__.__class__

>>> gadget.__class__.__class__

Normalement c’est à ce moment là que vous avez la Grande Révélation.

Faites “Ahhhhhhhhhhhhhhhhh”.

Donc la métaclasse, c’est le machin qui fabrique les classes, c’est une factory de classe. type est la métaclasse utilisée par défaut, mais vous pensez bien, chers amis, qu’on peut fabriquer ses propres métaclasses. Sinon ça serait pas marrant.

Ça marche comme ça :

class UneClasse(object):
  __metaclass__ = votre métaclasse
  [ le reste du code de la classe ]

Quand Python va voir ça, il ne va pas créer la classe immédiatement, il va d’abord suivre la chaîne d’héritage pour trouver quelle métaclasse utiliser pour fabriquer la classe :

Il va d’abord vérifier si il y a __metaclass__ de déclarée. Si ce n’est pas le cas, il va chercher dans les parents si ils ont un attribut __metaclass__. Si ce n’est pas le cas, il va utiliser type. Si Python trouve __metaclass__, alors il utilisera son contenu à la place de type.

Dans les deux cas, il va collecter toutes les informations sur la classe (le nom, les parents, les attributs), et les passer en paramètres à type ou votre métaclasse, et récupérer le résultat. Puis, seulement à ce moment là, il enregistre votre classe en mémoire.

Prenez votre temps sur ces paragraphes, c’est un peu la clé de tout le tuto.

Bon, nouvelle révélation : une métaclasse n’a pas besoin d’être une classe.

Je sais, c’est idiot d’appeler un truc “métaclasse” si ça n’a pas besoin d’être une classe. Mais on parle de la fonctionnalité qui utilise type pour un truc qui n’a rien à voir. Ça devait être le jour du beaujolais nouveau quand ils ont introduit la feature.

En fait, une métaclasse peut être n’importe quel callable qui retourne une classe, donc une fonction toute conne fait très bien l’affaire.

Le but de la métaclasse, c’est d’intercepter la création de la classe afin de la modifier, et voici ce que ça donne :

# une métaclasse DOIT avoir la même signature que type() puisque
# Python va lui passer tout ça automatiquement en paramètre

def prefixer(nom, parents, attributs):
    """
        On va créer une métaclasse qui prend tous les noms de méthodes,
        et les préfixes du mot "attaque". Oui ça ne sert à rien. Mais
        les usages des métaclasses qui servent à quelque chose sont
        généralement très compliqués.
    """

    # On crée un nouveau dictionnaire d'attributs avec les noms préfixés
    # On fait gaffe à pas modifier les __méthodes_magique__.
    nouveaux_attributs = {}
    for nom, val in attributs.items():
        if not nom.startswith('__'):
            nouveaux_attributs['attaque_' + nom] = val
        else:
            nouveaux_attributs[nom] = val

    # On délègue la création de la classe à type() :
    return type(nom, parents, nouveaux_attributs)

L’utilisation est toute simple, on écrit une classe normale, et on lui rajoute __metaclass__:

>>> class Ronflex(object):

    __metaclass__ = prefixer

    def armure(self):
        print("defense +15")

    def dodo(self):
        print("zzzzzz")
>>> r = Ronflex()
>>> r.attaque_armure()
defense +15
>>> r.attaque_dodo()
zzzzzz
>>> r.dodo()
Traceback (most recent call last):
  File "", line 1, in 
    r.dodo()
AttributeError: 'armure' object has no attribute 'dodo'

Voilà, c’est à peu près tout ce qu’il y a à comprendre des métaclasses :

1. On intercepte la création classe.
2. On modifie les paramètres.
3. On retourne la classe customisée.

Maintenant, la grande question : à quoi ça sert ?

Généralement, ça sert à faire de jolies APIs. Par exemple, les ORM (peewee, SQLAlchemy, l’ORM de Django) utilisent les métaclasses pour avoir un style déclaratif :

class Article(Model):
    titre = model.CharField()

Ici, Model va contenir une métaclasse, comme c’est un parent, la métaclasse sera aussi appelée pour Article, et elle peut donc agir pour modifier titre à la volée.

En effet, quand vous faites :

>>> art = Article.get(id=13)
>>> art.titre
u'Python pour les méca-scriptophiles'

Avec un ORM, vous récupérez la valeur de titre dans la base de données et non un CharField(). C’est le but : cacher des requêtes SQL et donner l’impression de manipuler des objets.

Ici le rôle de la métaclasse, c’est de prendre tous les attributs de types xxxField(), et modifier la classe pour qu’accéder à l’attribut fasse la requête voulue à la base de données.

On peut aussi utiliser les métaclasses pour faire des vérifications : s’assurer que la classe n’utilise pas un nom que vous voulez réserver, ou qu’elle contient bien un attribut.

Il y a même des implémentations d’interfaces (ou plutôt de l’équivalent des classes abstraites en Java) pour Python utilisant les métaclasses. Je ne suis pas convaincu par leur utilité, mais c’est possible.

Soyez prophètes

C’est pas le tout, mais maintenant que vous avez compris, il est temps de limer les bords pour que vous alliez porter la bonne parole.

Donc déjà, bon à savoir : metaclass est un paramètre de classe en Python 3. Ca donne ça:

class DePython3(metaclass=votre_metaclasse)

Ensuite, il y des conventions de nommage. Tout comme on nomme self le premier paramètre des méthodes, et *args / **kwargs les paramètres dynamiques, les paramètres des métaclasses ont des noms conventionels. La métaclasse précédente s’écrirait donc plus proprement :

def prefixer(name, bases, dct):
    nouveaux_attributs = {}
    for nom, val in dct.items():
        if not nom.startswith('__'):
            nouveaux_attributs['attaque_' + nom] = val
        else:
            nouveaux_attributs[nom] = val

    # On délègue la création de la classe à type() :
    return type(name, bases, nouveaux_attributs)

Enfin, souvenez-vous que les métaclasses ne fonctionnent qu’avec les New Style classes, donc celles qui héritent de object.

Par ailleurs, vous croiserez peut être des fois __metaclass__ en plein milieu d’un module (pas dans une classe donc). C’est une vieille façon de faire, qui affecte toutes les classes du module. Ce n’est plus recommandé.

Terminons sur une version de métaclasse qui fait la même chose que prefixer(), mais sous forme de classe. Parce que sinon à quoi ça sert que ça s’appelle une métaclasse, hein ?

# Oui, on peut hériter de type(), car c'est une classe, enfin une métaclasse.
# Mais pas sous forme de fonction. Sous forme de classe. Mais son nom
# est en minuscule, comme celui des classes int() et str(). Qui ne sont
# pas des métaclasses. Souvenez-vous : Beaujolais.
class Prefixer(type):

    # __new__ est le vrai constructeur en Python, et il retourne l'instance
    # en cours d'une classe. Or, qu'elle est l'instance d'une métaclasse ?
    # Une classe !
    def __new__(cls, name, bases, dct):

        nouveaux_attributs = {}
        for nom, val in dct.items():
            if not nom.startswith('__'):
                nouveaux_attributs['attaque_' + nom] = val
            else:
                nouveaux_attributs[nom] = val

        # On délègue la création de la classe à son parent.
        # Notez que cls doit être passé de bout en bout, ce qui n'est pas
        # le cas d'habitude avec 'self'
        return super(Prefixer, cls).__new__(cls, name, bases, nouveaux_attributs)

Et ça s’utilise pareil

>>> class Ronflex(object):
    __metaclass__ = Prefixer
    def armure(self):
        print("defense +15")
    def dodo(self):
        print("zzzzzz")
...
>>> r = Ronflex()
>>> r.attaque_dodo()
zzzzzz
>>> r.attaque_armure()
defense +15
>>> r.dodo()
Traceback (most recent call last):
  File "", line 1, in 
    r.dodo()
AttributeError: 'Ronflex' object has no attribute 'dodo'

Pourquoi utiliser une classe plutôt qu’une fonction alors que c’est vraiment plus compliqué ?

Et bien l’avantage d’utiliser une classe est qu’elle peut avoir des attributs et hériter. Car bien entendu, on peut avoir des metaclasses, qui héritent de metaclasses, et ainsi de suite, jusqu’à ce que du Lisp paraisse avoir du sens en comparaison.

On peut même faire plus vicieux et utiliser __call__ au lieu de __new__:

# on hérite plus de type, rien à foutre
class Prefixer(object):

    def __init__(self, prefix='attaque'):
        self.prefix = prefix

    # __call__ est la méthode appelée automatiquement quand on ajoute () après
    # un nom d'objet. Ca permet de rendre un objet callable. En gros, ça nous
    # permet d'utiliser une instance de Prefixer() comme une fonction
    def __call__(self, name, bases, dct):

        nouveaux_attributs = {}
        for nom, val in dct.items():
            if not nom.startswith('__'):
                nouveaux_attributs[self.prefix + nom] = val
            else:
                nouveaux_attributs[nom] = val

        return type(name, bases, nouveaux_attributs)

Et c’est sympa car du coup on peut passer des paramètres à notre métaclasse :

>>> class Ronflex(object):
    __metaclass__ = Prefixer(prefix='tatayoyo_')
    def armure(self):
        print("defense +15")
    def dodo(self):
        print("zzzzzz")
...         
>>> r = Ronflex()
>>> r.tatayoyo_dodo()
zzzzzz

Voilà, vous avez vu le visage de Dieu en face. C’est comme ça qu’il fabrique le monde.

Ah mais attendez ? Si type() est la métaclasse de tous les objets ? Qu’est-ce qui et la métaclasse de type() ?

>>> type.__class__

Je vous laisse méditer sur cette découverte métaphysique.

Après avoir lu la partie précédente, vous avez dû vous demander comment mettre tout ça en application.

Comme je vous l’avais expliqué, l’orienté objet est particulièrement adapté à la création de belles APIs. Nous allons donc étudier aujourd’hui un cas réel de mise en pratique réussi avec la lib path.py.

J’ai choisi cette lib car :

• Le code tient dans un seul fichier.
• Il y a plein de patterns utilisés dedans qui sont intéressants à expliquer.
• C’est une source propre qui suit globalement les bonnes pratiques.
• Path.py a une API élégante, donc le résultat à l’usage est un bon exemple.

Petit rappel, path.py est une surcouche au dessus des modules tempfile, os ou encore shutil, c’est à dire qu’elle permet de faire exactement la même chose, en plus pratique.

C’est donc typiquement un bibliothèque de confort, et elle n’aurait aucun intérêt si elle n’était pas agréable à utiliser puisque l’on peut déjà faire tout ce qu’elle fait avec Python en standard. Son attractivité réside dans la beauté de son interface qui rend la manipulation de fichiers très intuitive :

# elle permet de manipuler des chemins facilement
from path import path
dossier = path('/etc')
fichier = dossier / 'postgresql/9.1/main/pg_hba.conf'

# d'obtenir des informations sur le fichier
fichier.exists()
## True
fichier.parent
## path(u'/etc/postgresql/9.1/main')
fichier.basename()
## path(u'pg_hba.conf')
fichier.dirname()
## path(u'/etc/postgresql/9.1/main')
fichier.spli
fichier.split       fichier.splitall    fichier.splitdrive  fichier.splitext    fichier.splitlines  fichier.splitpath   fichier.splitunc
fichier.splitext()
## (path(u'/etc/postgresql/9.1/main/pg_hba'), u'.conf')


# lister les fichiers dans un dossier
for fichier in dossier.listdir():
...     print fichier
...
## /etc/thunderbird
## /etc/libpaper.d
## /etc/mtools.conf
## ...

# lister récursivement les fichiers dans un dossier
for fichier in (dossier / 'apt/').walkfiles():
    print fichier
...
## /etc/apt/sources.list.save
## /etc/apt/sources.list
## /etc/apt/trusted.gpg
## /etc/apt/trusted.gpg~
## /etc/apt/sources.list.d/indicator-brightness-ppa-raring.list.save
## /etc/apt/sources.list.d/tualatrix-ppa-raring.list
## /etc/apt/sources.list.d/webupd8team-sublime-text-2-raring.list
## /etc/apt/sources.list.d/fossfreedom-byzanz-raring.list.save
## /etc/apt/sources.list.d/hotot-team-ppa-raring.list.save
## /etc/apt/sources.list.d/webupd8team-y-ppa-manager-raring.list
## /etc/apt/sources.list.d/pitti-postgresql-raring.list.save
## /etc/apt/sources.list.d/pitti-postgresql-raring.list
## /etc/apt/sources.list.d/yorba-ppa-raring.list.save
## /etc/apt/sources.list.d/indicator-brightness-ppa-raring.list
## /etc/apt/sources.list.d/webupd8team-sublime-text-2-raring.list.save
## /etc/apt/sources.list.d/yorba-ppa-raring.list
## /etc/apt/sources.list.d/webupd8team-y-ppa-manager-raring.list.save
## /etc/apt/sources.list.d/fossfreedom-byzanz-raring.list
## /etc/apt/trustdb.gpg
## /etc/apt/apt.conf.d/20dbus
## /etc/apt/apt.conf.d/10periodic
## /etc/apt/apt.conf.d/99synaptic
## /etc/apt/apt.conf.d/70debconf
## /etc/apt/apt.conf.d/05aptitude
## /etc/apt/apt.conf.d/20archive
## /etc/apt/apt.conf.d/01autoremove
## /etc/apt/apt.conf.d/50unattended-upgrades
## /etc/apt/apt.conf.d/00aptitude
## /etc/apt/apt.conf.d/99update-notifier
## /etc/apt/apt.conf.d/15update-stamp
## /etc/apt/apt.conf.d/00trustcdrom
## /etc/apt/apt.conf.d/20changelog
## /etc/apt/apt.conf.d/01autoremove-kernels

# et bien d'autres choses

Nous allons donc commenter son code, dans le cadre du tuto (on ne va pas voir les algos en détail). Je mettrai mes commentaires entre #< sm > afin de les distinguer du reste.

#
# On commence par un bon gros bloc de copyright, sachant que path.py est
# sous MIT License. Le plus inhabituel c'est l'absence de déclaration
# d'encoding en en-tête, qui s'explique par le fait que toute la lib est
# écrite uniquement avec des caractères ASCII, ce qui est l'encodage par
# défaut de Python 2.7. Python 3 a UTF8 en encodage par défaut, mais ASCII
# est un sous-ensemble de UTF8, donc ça ne pose pas de problème.

# Notez qu'avec mes commentaires en plus, ça ferait planter le script puisque
# j'utilise des accents.
#

#
# Copyright (c) 2010 Mikhail Gusarov
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
#

#
# La docstring du module qui documente l'usage général du module. En
# l'occurence au moins l'existence de la classe principale et son usage. Les
# symboles comme '\x40' sont juste une autre représentation d'un caractère
# via sa valeur dans la table ASCII.

# Par exemple, '@' est à la case 64 dans la table ASCII, et 64 se note 40 en
# hexadécimal:

# >>> ord('@')
# 64
# >>> int('40', base=16)
# 64

# Du coup on peut écrire '@' juste avec un caractère d’échappement en Python
# qui va faire le lien. Cette technique est utile si on veut faire passer
# du texte avec des caractères spéciaux dans certains protocoles, par exemple
# quand on veut rentrer un email dans une URL. En l’occurrence je ne vois
# absolument pas ce que ça vient foutre ici.
#


""" path.py - An object representing a path to a file or directory.

Original author:
 Jason Orendorff 

Current maintainer:
 Jason R. Coombs 

Contributors:
 Mikhail Gusarov 
 Marc Abramowitz 
 Jason R. Coombs 
 Jason Chu 
 Vojislav Stojkovic 

Example::

    from path import path
    d = path('/home/guido/bin')
    for f in d.files('*.py'):
        f.chmod(0755)

path.py requires Python 2.5 or later.
"""


#
# Import du mot clé with, car cette lib est compatible avec Python 2.5
# et le keyword est apparu en 2.6. Il a été backporté dans __future__
#
from __future__ import with_statement

import sys #Informations sur le système
import warnings #Alertes techniques à d'autres dev
import os #Manipulation du File System
import fnmatch #Pattern matching comme dans un shell
import glob #Lister des fichier avec la syntax shell
import shutil #Manipulation de fichiers de haut niveau
import codecs #Encoding
import hashlib #Sommes de contrôle
import errno #Les codes d'erreurs liées aux fichiers.
import tempfile #Création de fichiers temporaires
import functools #Manipulation des fonctions

#
# Tentative d'utilisation de la lib win32security qui sert à gérer
# des aspects sécuritaires du FS sous Windows. C'est une lib tierce partie,
# et une dépendance optionelle, donc l'import est géré pour ne pas faire
# d'erreur si la lib n'est pas disponible.

# Idem pour pwd qui est dans la lib standard mais uniquement sur les distribs
# unix et qui donne accès aux infos sur l'utilisateur du système, tester
# son mot de passe, etc.
#
try:
    import win32security
except ImportError:
    pass

try:
    import pwd
except ImportError:
    pass



#
# Manière standard de lister la version de la lib dans un module Python.

# __all__ est une variable magique qui peut contenir une liste des noms de
# tout ce qui est importable dans le module, de telle sorte que si
# quelqu'un fait : from path import *, seul le contenu de __all__ soit
# importé.
#
__version__ = '3.0'
__all__ = ['path']


#
# Les warnings ressemblent beaucoup aux exceptions excepté qu'ils ne font
# pas planter le programme. Ici donc, ou hérite de la base des warnings
# comme on le ferait pour créer son Exception personnalisée, ce qui va
# permettre à l'utilisateur de la lib path.py de, plus tard, pouvoir filter
# ce warning en particulier.
#


class TreeWalkWarning(Warning):
    pass


#
# Un décorateur de mémorisation, c'est à dire qui va mettre en cache les
# résultats de la fonction sur lequel il est appliqué afin que les prochains
# appels avec les mêmes paramètres lisent les valeurs du cache en mémoire
# plutôt que de refaire l'opération.

# Il est utilisé plus bas sur :

#     @classmethod
#     @simple_cache
#     def using_module(cls, module):
#         subclass_name = cls.__name__ + '_' + module.__name__
#         bases = (cls,)
#         ns = {'module': module}
#         return type(subclass_name, bases, ns)

# Ça évitera plusieurs traitements de using_module() si le paramètre de
# 'module' ne change pas.

# Et oui, on peut mélanger plusieurs classes et fonctions dans un même module,
# ça n'a pas d'importance.

#
def simple_cache(func):
    """
    Save results for the 'using_module' classmethod.
    When Python 3.2 is available, use functools.lru_cache instead.
    """
    saved_results = {}
    def wrapper(cls, module):
        if module in saved_results:
            return saved_results[module]
        saved_results[module] = func(cls, module)
        return saved_results[module]
    return wrapper


#
# Nous avons vu que les propriétés permettaient de déguiser une méthode
# en attribut. Cela ne marche pas sur une méthode de classe car dans ce cas
# la propriété va se retourner elle-même.
# Cette classe hérite de property pour écraser ce comportement et bien
# retourner la valeur de la méthode de classe.

# Elle est utilisée plus loin dans:

#     @ClassProperty
#     @classmethod
#     def _next_class(cls):
#         """
#         What class should be used to construct new instances from this class
#         """
#         return cls

# Ce qui va permettre de faire path._next_class au lieu de path._next_class().

# C'est cosmétique, mais c'est le but de la lib d'être jolie.
#
class ClassProperty(property):
    def __get__(self, cls, owner):
        return self.fget.__get__(None, owner)()

#
# Encore un décorateur, cette fois sous forme de classe (on ne les a pas vu)
# Celui-ci, quand il est appliqué, sert à ce qu'une méthode soit à la fois
# une méthode d'instance et une méthode de classe, le choix se faisant
# dynamiquement selon la situation.

# Par exemple dans:

#     @multimethod
#     def joinpath(cls, first, *others):
#         """
#         Join first to zero or more path components, adding a separator
#         character (first.module.sep) if needed.  Returns a new instance of
#         first._next_class.
#         """
#         if not isinstance(first, cls):
#             first = cls(first)
#         return first._next_class(first.module.join(first, *others))

# 'cls' sera une instance ou une classe selon que l'appel se fasse depuis la
# classe ou l'instance.

# Notez le nom de la classe qui n'est pas en CamelCase (pas de majuscule)
# alors qu'il s'agit bien d'un classe. Comme c'est un décorateur, on a
# l'habitude de les voir en minuscule, donc on laisse ce nom en minuscule.
# C'est une des rares exceptions au PEP8 (on en verra d'autres plus bas)
# qu'on peut se permettre quand on sait ce qu'on fait :-)
#
class multimethod(object):
    """
    Acts like a classmethod when invoked from the class and like an
    instancemethod when invoked from the instance.
    """
    def __init__(self, func):
        self.func = func

    def __get__(self, instance, owner):
        return (
            functools.partial(self.func, owner) if instance is None
            else functools.partial(self.func, owner, instance)
        )


#
# La classe principale, et le plus gros morceau de code. Une classe peut
# tout à fait faire plusieurs centaines de lignes.

# En général je recommande de ne pas avoir de fichiers qui fait plus de 500
# lignes en Python, mais ici le but est clairement de faire une lib qui tient
# dans un fichier pour l'auteur.

# La classe hérite du type unicode (hé oui, on peut hériter des types
# built-in !); ainsi le path peut être manipulé comme une chaîne et reste
# compatible avec tous les outils existants de manipulation de nom de fichiers
# car ils utilisent les chaînes.

# L'héritage est une techno qui sert donc aussi à conserver des compatibilités
# et des comportements existants / attendus.

# Encore une fois le nom est en minuscule alors que c'est une classe, c'est une
# autre exception : quand on crée un type de base, on le met en minuscule
# car c'est ce que fait la lib standard (int(), str(), list(), datetime(),
# unicode(), etc, sont en fait des classes).

# La docstring pourrait être meilleure.
#
class path(unicode):
    """ Represents a filesystem path.

    For documentation on individual methods, consult their
    counterparts in os.path.
    """

    #
    # Probablement mon désaccord principal avec cette lib, l'init vérifie
    # qu'on lui passe bien une chaîne alors que j'aurais choisi le duck typing.
    #

    def __init__(self, other):
        if not isinstance(other, basestring):
            raise TypeError("path must be a string")

    #
    # L'auteur stocke la référence de os.path ici, et l'utilise partout à la
    # place d'utiliser os.path directement. Cela permet de changer ce module à
    # la volée, par exemple pour utiliser spécifiquement le module dédié à
    # Windows ou à unix au lieu de celui choisit automatiquement.

    # C'est un exemple de pattern stratégie.

    # Et non, la docstring n'a aucun effet. Ça pourrait être un comment.
    # En revanche, comme spécifié en comment, certains outils comme sphinx
    # prennent les docstring en compte sur les variables.

    #

    module = os.path
    "The path module to use for path operations."


    #
    # Une méthode retourne une classe path dont le module est
    # celui passé en paramètre. Pratique si vous voulez
    # utiliser un module spécifique à un OS depuis un autre
    # mais juste ponctuellement.
    # Par exemple sous Windows, vous voulez traiter un chemin
    # (mais un seul, le reste est sous Windows) Unix, vous
    # pouvez faire :
    #
    # >>> import posixpath
    # >>> p = path.using_module(posixpath)('/etc')
    # >>> print p
    # /etc
    # >>> p
    # path_posixpath(u'/etc')

    # ce qui crée un objet path() dont l'attribut 'module' est le module
    #  posixpath. C'est une application concrète de l'injection de dépendance.

    #
    @classmethod
    @simple_cache
    def using_module(cls, module):
        subclass_name = cls.__name__ + '_' + module.__name__
        bases = (cls,)
        ns = {'module': module}
        return type(subclass_name, bases, ns)


    #
    # Une propriété qui retourne la classe (oui, on peut retourner une CLASSE)
    # à utiliser si on veut créer une nouvelle instance de cette classe.

    # C'est très abstrait, vous n'aurez pas à faire ça tous les jours.

    # C'est une méthode placée là pour permettre un maximum de configurabilité
    # : si vous changez cette classe, certaines méthodes renverront un autre
    # type plutôt que le type en cours. Utile pour certains cas où vous voulez
    # hériter de path() mais désirez un comportement spécial pour la création
    # de nouveaux path.
    #
    @ClassProperty
    @classmethod
    def _next_class(cls):
        """
        What class should be used to construct new instances from this class
        """
        return cls

    # --- Special Python methods.

    #
    # Là on attaque la définition de toutes les méthodes magiques.
    # Essentiellement pour overrider le comportement par défaut des chaînes
    # unicode et exposer une API sympa.
    #


    #
    # Dans le shell, un path s'affichera path('chemin') et non 'chemin'
    # L'auteur affiche en fait le nom du type en cours (en cas d'héritage
    # cela changera) et ensuite la représentation du parent, en l'occurence
    # la classe unicode().
    #
    def __repr__(self):
        return '%s(%s)' % (type(self).__name__, super(path, self).__repr__())


    #
    # Override l'addition.
    # path('truc') + 'machin' donne path('trucmachin')
    #
    # Adding a path and a string yields a path.
    def __add__(self, more):
        try:
            return self._next_class(super(path, self).__add__(more))
        except TypeError:  # Python bug
            return NotImplemented

    #
    # 'machin' + path('truc') donne path('trucmachin')
    #
    def __radd__(self, other):
        if not isinstance(other, basestring):
            return NotImplemented
        return self._next_class(other.__add__(self))

    #
    # Override la division.
    # path('truc') / 'machin' donne path('truc/machin')
    #
    # The / operator joins paths.
    def __div__(self, rel):
        """ fp.__div__(rel) == fp / rel == fp.joinpath(rel)

        Join two path components, adding a separator character if
        needed.
        """
        return self._next_class(self.module.join(self, rel))

    #
    # Petite astuce de compatibilité si le mec a fait
    # from __future__ import division ou si on est en Python 3
    #
    # Remarque : on peut définir des attributs de classe n'importe où, et pas
    # seulement en haut de la classe.
    #

    # Make the / operator work even when true division is enabled.
    __truediv__ = __div__

    #
    # path() est aussi un context manager qu'on peut utiliser avec with !

    # with path('truc'):
    #     tout ce qui est ici se fait dans le dossier truc

    # *_ n'est pas une notation qui a un effet spécial. '_' est un nom de
    # variable valide, c'est une convention pour dire 'je ne vais pas me
    # servir de cet argument, je le déclare juste pour respecter la signature'
    # et '*' est l'opérateur de paramétrage dynamique. '*_' est donc l'auteur
    # signalant qu'il accepte n'importe quels paramètres positionnels, mais
    # qu'ils ne les utilisera pas.
    #
    def __enter__(self):
        self._old_dir = self.getcwd()
        os.chdir(self)

    def __exit__(self, *_):
        os.chdir(self._old_dir)


    #
    # Le résultat de os.getcwdu(), mais retourne un objet path().
    # Une bonne part du travail de la lib consiste à wrapper les méthodes
    # ordinaires des autres modules pour qu'elles retournent un type path()
    # pour qu'après on puisse faire des '.parent' ou utiliser '/' dessus
    # sans y penser.
    #

    @classmethod
    def getcwd(cls):
        """ Return the current working directory as a path object. """
        return cls(os.getcwdu())

    #
    # --- Operations on path strings.

    #
    # On enchaine ici des wrappers sur des méthodes de os.path (ou son
    # remplaçant dans self.module), que l'objet s'applique à lui-même (self).
    # Comme la classe hérite de 'unicode', toutes ces méthodes marchent.
    # Et comme self._next_class retourne la classe pour créer le prochain
    # path, on retourne toujours un objet de type 'path'.

    # Si on fait fi des abstractions et qu'on lit les valeurs par défaut,

    #     self._next_class(self.module.abspath(self))

    # fait en fait:

    #     path(os.path.abspath('ton_chemin'))

    # Ce qui donne l'API suivante quand on utilise la lib :

    #     >>> path('/etc/nginx/..').abspath()
    #     path(u'/etc')
    #

    def abspath(self):
        return self._next_class(self.module.abspath(self))

    def normcase(self):
        return self._next_class(self.module.normcase(self))

    def normpath(self):
        return self._next_class(self.module.normpath(self))

    def realpath(self):
        return self._next_class(self.module.realpath(self))

    def expanduser(self):
        return self._next_class(self.module.expanduser(self))

    def expandvars(self):
        return self._next_class(self.module.expandvars(self))

    def dirname(self):
        return self._next_class(self.module.dirname(self))

    def basename(self):
        return self._next_class(self.module.basename(self))


    #
    # Là on rentre dans les méthodes utilitaires. L'auteur a constaté qu'on
    # appelait très souvent ces trois méthodes sur les chemin des fichiers de
    # config genre '~/toto' pour obtenir '/home/sam/toto' et propose donc
    # un shortcut pour le faire car honnêtement, qui se souvient du nom
    # de ces 3 méthodes à enchaîner pour obtenir un truc bullet proof ?
    # Règle d'or d'une belle API : si il faut regarder dans la doc à chaque
    # fois qu'on utilise quelque chose, il faut écrire un meilleur code.
    #

    def expand(self):
        """ Clean up a filename by calling expandvars(),
        expanduser(), and normpath() on it.

        This is commonly everything needed to clean up a filename
        read from a configuration file, for example.
        """
        return self.expandvars().expanduser().normpath()


    #
    # Les méthodes suivantes sont préfixées d'un '_', donc elle n'apparaîtront
    # pas dans les résultats d'outils avec complétion du code. Cela nous
    # indique qu'il s'agit d'un détail d'implémentation, et que l'on ne devrait
    # pas l'utiliser en dehors de la classe. Rien n'empêche de le faire
    # cependant si vous avez envie de faire un beau hack bien gras.

    # Ici l'auteur fait ce choix car il va enrober ces appels dans des
    # propriétés pour les déguiser en attributs.

    # Ces 3 méthodes retournent respectivement l'extension de fichier, le nom
    # de fichier sans extension, et la lettre de lecteur sur les chemins
    # windows.
    #

    def _get_namebase(self):
        base, ext = self.module.splitext(self.name)
        return base

    def _get_ext(self):
        f, ext = self.module.splitext(self)
        return ext

    def _get_drive(self):
        drive, r = self.module.splitdrive(self)
        return self._next_class(drive)


    #

    # Malgré l'indentation bizarre, il s'agit bien de :

    #     attribut_de_classe = function(arg1, arg2, arg3, arg4)


    # Dans les tutos précédents vous avez vu comment créer une propriété avec
    # le décorateur @property.

    # Ici l'auteur utilise l'ancienne façon de faire, car il veut garder la
    # compatibilité avec python 2.5.

    # C'est globalement la même chose, par exemple ici l'attribut 'namebase'
    # est défini comme une property et y accéder en lecture va appeler la
    # méthode '_get_namebase'. Le second et le troisième argument de
    # property() sont les setter et les deleter qui ne sont pas ici définis et
    # mis à None (donc l'attribut est en lecture seule). Le dernier argument
    # est la docstring.

    #

    parent = property(
        dirname, None, None,
        """ This path's parent directory, as a new path object.

        For example, path('/usr/local/lib/libpython.so').parent == path('/usr/local/lib')
        """)

    name = property(
        basename, None, None,
        """ The name of this file or directory without the full path.

        For example, path('/usr/local/lib/libpython.so').name == 'libpython.so'
        """)

    namebase = property(
        _get_namebase, None, None,
        """ The same as path.name, but with one file extension stripped off.

        For example, path('/home/guido/python.tar.gz').name     == 'python.tar.gz',
        but          path('/home/guido/python.tar.gz').namebase == 'python.tar'
        """)

    ext = property(
        _get_ext, None, None,
        """ The file extension, for example '.py'. """)

    drive = property(
        _get_drive, None, None,
        """ The drive specifier, for example 'C:'.
        This is always empty on systems that don't use drive specifiers.
        """)

    #
    # Encore des wrappers pour retourner des objets path(). La structure
    # est classique: définition de méthodes courtes avec docstring.

    # L'auteur retourne un tuple comme les méthodes originales (autant
    # changer le comportement attendu le moins possible), mais cast la
    # première partie du tuple en objet path().
    #

    def splitpath(self):
        """ p.splitpath() -> Return (p.parent, p.name). """
        parent, child = self.module.split(self)
        return self._next_class(parent), child

    def splitdrive(self):
        """ p.splitdrive() -> Return (p.drive, ).

        Split the drive specifier from this path.  If there is
        no drive specifier, p.drive is empty, so the return value
        is simply (path(''), p).  This is always the case on Unix.
        """
        drive, rel = self.module.splitdrive(self)
        return self._next_class(drive), rel

    def splitext(self):
        """ p.splitext() -> Return (p.stripext(), p.ext).

        Split the filename extension from this path and return
        the two parts.  Either part may be empty.

        The extension is everything from '.' to the end of the
        last path segment.  This has the property that if
        (a, b) == p.splitext(), then a + b == p.
        """
        filename, ext = self.module.splitext(self)
        return self._next_class(filename), ext

    #
    # Ici on a des méthodes légèrement différentes de celles qu'elles wrappent.
    # C'est vraiment pour se faciliter la tâche sur les opérations courantes
    # et sauver quelques caractères à la frappe.
    #

    def stripext(self):
        """ p.stripext() -> Remove one file extension from the path.

        For example, path('/home/guido/python.tar.gz').stripext()
        returns path('/home/guido/python.tar').
        """
        return self.splitext()[0]

    def splitunc(self):
        unc, rest = self.module.splitunc(self)
        return self._next_class(unc), rest

    @property
    def uncshare(self):
        """
        The UNC mount point for this path.
        This is empty for paths on local drives.
        """
        unc, r = self.module.splitunc(self)
        return self._next_class(unc)

    #
    # joinpath cast le premier argument si il n'est pas du même type que la
    # classe en cours. Il n'y a pas de raison apparente, donc je suppose que
    # c'est pour éviter une bug qu'ils ont découvert dans une situation
    # borderline
    #

    @multimethod
    def joinpath(cls, first, *others):
        """
        Join first to zero or more path components, adding a separator
        character (first.module.sep) if needed.  Returns a new instance of
        first._next_class.
        """
        if not isinstance(first, cls):
            first = cls(first)
        return first._next_class(first.module.join(first, *others))


    #
    # Puis on arrive enfin dans les méthodes métiers qui ne sont pas dans les
    # modules. Typiquement ce seront des méthodes plus longues et inconnues
    # car n'existant pas dans les autres modules donc :
    # - on les met à la fin
    # - la docstring est plus explicite.
    # Ici splitall permet de faire :

    # >>> path('/usr/lib/python2.7/fnmatch.pyc').splitall()
    # [path(u'/'), u'usr', u'lib', u'python2.7', u'fnmatch.pyc']

    # Ce que os.path ne permet pas de faire directement.

    #

    def splitall(self):
        r""" Return a list of the path components in this path.

        The first item in the list will be a path.  Its value will be
        either os.curdir, os.pardir, empty, or the root directory of
        this path (for example, ``'/'`` or ``'C:\\'``).  The other items in
        the list will be strings.

        ``path.path.joinpath(*result)`` will yield the original path.
        """
        parts = []
        loc = self
        while loc != os.curdir and loc != os.pardir:
            prev = loc
            loc, child = prev.splitpath()
            if loc == prev:
                break
            parts.append(child)
        parts.append(loc)
        parts.reverse()
        return parts


    #

    # Voici une bonne pratique, avoir une méthode complexe (ici relpathto(),
    # qui crée un chemin relatif du path() courant vers un autre dossier), et
    # son opposée plus simple (ici relpath(), qui crée un chemin relatif d'un
    # dossier vers le path courant) qui utilise la méthode précédente en en
    # inversant juste les paramètres.

    # En effet ça ne sert à rien d'écrire deux fois la même méthode, on
    # factorise ainsi du code et respecte le principe DRY (don't repeat
    # yourself).

    # relpathto() est un bon exemple d'un code assez complexe pour une
    # opération qui parait pourtant assez simple. C'est aussi un très bon
    # exemple de comment écrire des commentaires : on ne décrit pas les
    # opérations évidentes mais on explique les choses ambiguës et on met des
    # avertissements

    #

    def relpath(self, start='.'):
        """ Return this path as a relative path,
        based from start, which defaults to the current working directory.
        """
        cwd = self._next_class(start)
        return cwd.relpathto(self)

    def relpathto(self, dest):
        """ Return a relative path from self to dest.

        If there is no relative path from self to dest, for example if
        they reside on different drives in Windows, then this returns
        dest.abspath().
        """
        origin = self.abspath()
        dest = self._next_class(dest).abspath()

        orig_list = origin.normcase().splitall()
        # Don't normcase dest!  We want to preserve the case.
        dest_list = dest.splitall()

        if orig_list[0] != self.module.normcase(dest_list[0]):
            # Can't get here from there.
            return dest

        # Find the location where the two paths start to differ.
        i = 0
        for start_seg, dest_seg in zip(orig_list, dest_list):
            if start_seg != self.module.normcase(dest_seg):
                break
            i += 1

        # Now i is the point where the two paths diverge.
        # Need a certain number of "os.pardir"s to work up
        # from the origin to the point of divergence.
        segments = [os.pardir] * (len(orig_list) - i)
        # Need to add the diverging part of dest_list.
        segments += dest_list[i:]
        if len(segments) == 0:
            # If they happen to be identical, use os.curdir.
            relpath = os.curdir
        else:
            relpath = self.module.join(*segments)
        return self._next_class(relpath)

    # --- Listing, searching, walking, and matching

    #
    # un simple wrapper mais qui rajoute un argument en plus : un pattern à la
    # unix. C'est une extension naturelle, et c'est le genre de chose que vous
    # vouliez faire et vous vous êtes toujours demandé : "mais pourquoi
    # c'est pas par défaut ?" ou "comment on fait ça facilement ?" Si vous
    # vous posez ce genre de question, étendez un peu les comportements
    # initiaux. Rajouter un argument ne rend pas le comportement différent du
    # précédent grâce au paramètre par défaut mis à None, donc c'est tout
    # bénef.
    #

    def listdir(self, pattern=None):
        """ D.listdir() -> List of items in this directory.

        Use D.files() or D.dirs() instead if you want a listing
        of just files or just subdirectories.

        The elements of the list are path objects.

        With the optional 'pattern' argument, this only lists
        items whose names match the given pattern.
        """
        names = os.listdir(self)
        if pattern is not None:
            names = fnmatch.filter(names, pattern)
        return [self / child for child in names]

    #
    # Dans la même lignée de ce qu'on a vu plus haut: utiliser une fonction
    # plus complexe (qui déjà étend un comportement par défaut) pour en
    # faire encore une méthode plus spécialisée.

    # L'avantage de cette approche c'est que le code est plein de petites
    # briques:

    # vous avez listdir(), qui est assez court (mais déjà plus puissant),
    # puis dirs() et files(), qui font la même chose en plus spécialisés.

    # L'alternative aurait été d'ajouter une param à listdir() et ne pas
    # créer dirs() et files(), mais ça aurait rajouté un if dans le code et
    # un paramètre qui fait rechercher dans la doc celui qui l'utilise et
    # celui qui lit le code.

    # Avec l'approche actuelle, l'API est très claire :

    # for d in path('/etc').dirs()

    # On s'attend à lire tous les dossiers de /etc. Et les
    # méthodes restent courtes.

    #

    def dirs(self, pattern=None):
        """ D.dirs() -> List of this directory's subdirectories.

        The elements of the list are path objects.
        This does not walk recursively into subdirectories
        (but see path.walkdirs).

        With the optional 'pattern' argument, this only lists
        directories whose names match the given pattern.  For
        example, ``d.dirs('build-*')``.
        """
        return [p for p in self.listdir(pattern) if p.isdir()]

    def files(self, pattern=None):
        """ D.files() -> List of the files in this directory.

        The elements of the list are path objects.
        This does not walk into subdirectories (see path.walkfiles).

        With the optional 'pattern' argument, this only lists files
        whose names match the given pattern.  For example,
        ``d.files('*.pyc')``.
        """

        return [p for p in self.listdir(pattern) if p.isfile()]


    #

    # walk() et ses pendants walkdirs() et walkfiles() sont des alternatives
    # au très peu intuitif os.path.walk qui permet de traverser récursivement
    # un répertoire.

    # En effet, en Python les callbacks sont quelque chose qu'on utilise peu,
    # et à l'inverse, on itère beaucoup.

    # Cela permet de faire:

    # for f in path('/etc').walk_files():

    # Pour lister récursivement tous les fichiers de /etc et de ses sous
    # (et sous, sous, sous) dossiers.

    # C'est clair, c'est simple à comprendre et facile à utiliser.

    # L'auteur utilise ici 'yield', et c'est l'outil parfait pour cela.
    # Souvenez vous de 'yield' comme un très bon moyen de parcourir des choses
    # imbriquées comme si c'était une structure plate à une dimension.

    # Yield permet de transformer n'importe quelle méthode d'un objet en
    # un générateur sur un algorithme qui peut être très complexe, simplifiant
    # son utilisation. Pensez-y !

    # Sous le capot, c'est presque un appel récursif, si ce n'est qu'un nouvel
    # objet path() est créé à chaque fois, depuis lequel on fait walk().

    # Notez également que sur une méthode comme ça qui peut foirer facilement
    # (une opération sur des centaines de fichiers...), un paramètre permet
    # de choisir une gestion des erreurs parmi :

    # - lever une exception (qui est dans un code propre le choix par défaut)
    # - ignorer (pour faire un code tolérant aux erreurs)
    # - ou faire un retour sans erreur, mais avec un warning technique (utile
    #     pour le scripting)

    # Encore une fois, faire une classe, c'est l'occasion de penser à
    # l'utilisateur de la classe, ce qui a été ici bien fait.

    # Enfin, contrairement à ce qu'on pourrait attendre, walkdirs et walkfiles
    # n'utilisent pas walk(), ce qui est généralement fait pour des raisons de
    # performances (on sacrifie le DRY pour éviter un appel de callback
    # ou un test sur des grosses boucles), même si ici c'est une supposition.

    #

    def walk(self, pattern=None, errors='strict'):
        """ D.walk() -> iterator over files and subdirs, recursively.

        The iterator yields path objects naming each child item of
        this directory and its descendants.  This requires that
        D.isdir().

        This performs a depth-first traversal of the directory tree.
        Each directory is returned just before all its children.

        The errors= keyword argument controls behavior when an
        error occurs.  The default is 'strict', which causes an
        exception.  The other allowed values are 'warn', which
        reports the error via warnings.warn(), and 'ignore'.
        """
        if errors not in ('strict', 'warn', 'ignore'):
            raise ValueError("invalid errors parameter")

        try:
            childList = self.listdir()
        except Exception:
            if errors == 'ignore':
                return
            elif errors == 'warn':
                warnings.warn(
                    "Unable to list directory '%s': %s"
                    % (self, sys.exc_info()[1]),
                    TreeWalkWarning)
                return
            else:
                raise

        for child in childList:
            if pattern is None or child.fnmatch(pattern):
                yield child
            try:
                isdir = child.isdir()
            except Exception:
                if errors == 'ignore':
                    isdir = False
                elif errors == 'warn':
                    warnings.warn(
                        "Unable to access '%s': %s"
                        % (child, sys.exc_info()[1]),
                        TreeWalkWarning)
                    isdir = False
                else:
                    raise

            if isdir:
                for item in child.walk(pattern, errors):
                    yield item

    def walkdirs(self, pattern=None, errors='strict'):
        """ D.walkdirs() -> iterator over subdirs, recursively.

        With the optional 'pattern' argument, this yields only
        directories whose names match the given pattern.  For
        example, ``mydir.walkdirs('*test')`` yields only directories
        with names ending in 'test'.

        The errors= keyword argument controls behavior when an
        error occurs.  The default is 'strict', which causes an
        exception.  The other allowed values are 'warn', which
        reports the error via warnings.warn(), and 'ignore'.
        """
        if errors not in ('strict', 'warn', 'ignore'):
            raise ValueError("invalid errors parameter")

        try:
            dirs = self.dirs()
        except Exception:
            if errors == 'ignore':
                return
            elif errors == 'warn':
                warnings.warn(
                    "Unable to list directory '%s': %s"
                    % (self, sys.exc_info()[1]),
                    TreeWalkWarning)
                return
            else:
                raise

        for child in dirs:
            if pattern is None or child.fnmatch(pattern):
                yield child
            for subsubdir in child.walkdirs(pattern, errors):
                yield subsubdir

    def walkfiles(self, pattern=None, errors='strict'):
        """ D.walkfiles() -> iterator over files in D, recursively.

        The optional argument, pattern, limits the results to files
        with names that match the pattern.  For example,
        ``mydir.walkfiles('*.tmp')`` yields only files with the .tmp
        extension.
        """
        if errors not in ('strict', 'warn', 'ignore'):
            raise ValueError("invalid errors parameter")

        try:
            childList = self.listdir()
        except Exception:
            if errors == 'ignore':
                return
            elif errors == 'warn':
                warnings.warn(
                    "Unable to list directory '%s': %s"
                    % (self, sys.exc_info()[1]),
                    TreeWalkWarning)
                return
            else:
                raise

        for child in childList:
            try:
                isfile = child.isfile()
                isdir = not isfile and child.isdir()
            except:
                if errors == 'ignore':
                    continue
                elif errors == 'warn':
                    warnings.warn(
                        "Unable to access '%s': %s"
                        % (self, sys.exc_info()[1]),
                        TreeWalkWarning)
                    continue
                else:
                    raise

            if isfile:
                if pattern is None or child.fnmatch(pattern):
                    yield child
            elif isdir:
                for f in child.walkfiles(pattern, errors):
                    yield f

    def fnmatch(self, pattern):
        """ Return True if self.name matches the given pattern.

        pattern - A filename pattern with wildcards,
            for example ``'*.py'``.
        """
        return fnmatch.fnmatch(self.name, pattern)

    def glob(self, pattern):
        """ Return a list of path objects that match the pattern.

        pattern - a path relative to this directory, with wildcards.

        For example, path('/users').glob('*/bin/*') returns a list
        of all the files users have in their bin directories.
        """
        cls = self._next_class
        return [cls(s) for s in glob.glob(self / pattern)]

    #
    # --- Reading or writing an entire file at once.

    def open(self, mode='r'):
        """ Open this file.  Return a file object. """
        return open(self, mode)

    #

    # L'avantage d'avoir une classe comme point de départ de tout c'est que
    # c'est facile à manipuler dans le shell, surtout en autocompletion.

    # Donc il est bon de mettre quelques outils qui sont pratiques dans les
    # usages type shell.

    # Ici c'est exactement le cas : on fait des méthodes un peu bourrines (
    # globalement ça dump en mémoire ou ça écrit tout le fichier d'un coup),
    # mais très pratiques pour manipuler les objets dans un terminal.

    # Notez aussi le nettoyage opéré:

    #             return (t.replace(u'\r\n', u'\n')
    #                  .replace(u'\r\x85', u'\n')
    #                  .replace(u'\r', u'\n')
    #                  .replace(u'\x85', u'\n')
    #                  .replace(u'\u2028', u'\n'))

    # Ce n'est pas particulièrement lié à la POO, mais l'encapsulation de
    # ce genre de process est toujours le bienvenu. L'idée est que l'objet
    # puisse être utilisé comme une boîte noire en laquelle on a totalement
    # confiance.

    #


    def bytes(self):
        """ Open this file, read all bytes, return them as a string. """
        with self.open('rb') as f:
            return f.read()

    def write_bytes(self, bytes, append=False):
        """ Open this file and write the given bytes to it.

        Default behavior is to overwrite any existing file.
        Call p.write_bytes(bytes, append=True) to append instead.
        """
        if append:
            mode = 'ab'
        else:
            mode = 'wb'
        with self.open(mode) as f:
            f.write(bytes)

    def text(self, encoding=None, errors='strict'):
        r""" Open this file, read it in, return the content as a string.

        This method uses 'U' mode, so '\r\n' and '\r' are automatically
        translated to '\n'.

        Optional arguments:

        encoding - The Unicode encoding (or character set) of
            the file.  If present, the content of the file is
            decoded and returned as a unicode object; otherwise
            it is returned as an 8-bit str.
        errors - How to handle Unicode errors; see help(str.decode)
            for the options.  Default is 'strict'.
        """
        if encoding is None:
            # 8-bit
            with self.open('U') as f:
                return f.read()
        else:
            # Unicode
            with codecs.open(self, 'r', encoding, errors) as f:
                # (Note - Can't use 'U' mode here, since codecs.open
                # doesn't support 'U' mode.)
                t = f.read()
            return (t.replace(u'\r\n', u'\n')
                     .replace(u'\r\x85', u'\n')
                     .replace(u'\r', u'\n')
                     .replace(u'\x85', u'\n')
                     .replace(u'\u2028', u'\n'))

    #
    # Sur des méthodes avec de nombreux paramètres, ne pas hésiter
    # à mettre un maximum de valeurs par défaut "saines" (c'est à dire la
    # valeur du cas le plus courant ou pragmatique).

    # Comme c'est une grosse fonction très configurable, la docstring
    # est écrite en conséquence. Ne soyez pas timide avec la dosctring,
    # on peut la faire très très très longue, ce n'est pas une mauvaise
    # chose.

    # Notez que la docstring est préfixée d'un "r" ici, pour que Python
    # n'interprète pas les \n et \r.
    #

    def write_text(self, text, encoding=None, errors='strict', linesep=os.linesep, append=False):
        r""" Write the given text to this file.

        The default behavior is to overwrite any existing file;
        to append instead, use the 'append=True' keyword argument.

        There are two differences between path.write_text() and
        path.write_bytes(): newline handling and Unicode handling.
        See below.

        Parameters:

          - text - str/unicode - The text to be written.

          - encoding - str - The Unicode encoding that will be used.
            This is ignored if 'text' isn't a Unicode string.

          - errors - str - How to handle Unicode encoding errors.
            Default is 'strict'.  See help(unicode.encode) for the
            options.  This is ignored if 'text' isn't a Unicode
            string.

          - linesep - keyword argument - str/unicode - The sequence of
            characters to be used to mark end-of-line.  The default is
            os.linesep.  You can also specify None; this means to
            leave all newlines as they are in 'text'.

          - append - keyword argument - bool - Specifies what to do if
            the file already exists (True: append to the end of it;
            False: overwrite it.)  The default is False.


        --- Newline handling.

        write_text() converts all standard end-of-line sequences
        ('\n', '\r', and '\r\n') to your platform's default end-of-line
        sequence (see os.linesep; on Windows, for example, the
        end-of-line marker is '\r\n').

        If you don't like your platform's default, you can override it
        using the 'linesep=' keyword argument.  If you specifically want
        write_text() to preserve the newlines as-is, use 'linesep=None'.

        This applies to Unicode text the same as to 8-bit text, except
        there are three additional standard Unicode end-of-line sequences:
        u'\x85', u'\r\x85', and u'\u2028'.

        (This is slightly different from when you open a file for
        writing with fopen(filename, "w") in C or open(filename, 'w')
        in Python.)


        --- Unicode

        If 'text' isn't Unicode, then apart from newline handling, the
        bytes are written verbatim to the file.  The 'encoding' and
        'errors' arguments are not used and must be omitted.

        If 'text' is Unicode, it is first converted to bytes using the
        specified 'encoding' (or the default encoding if 'encoding'
        isn't specified).  The 'errors' argument applies only to this
        conversion.

        """
        if isinstance(text, unicode):
            if linesep is not None:
                # Convert all standard end-of-line sequences to
                # ordinary newline characters.
                text = (text.replace(u'\r\n', u'\n')
                            .replace(u'\r\x85', u'\n')
                            .replace(u'\r', u'\n')
                            .replace(u'\x85', u'\n')
                            .replace(u'\u2028', u'\n'))
                text = text.replace(u'\n', linesep)
            if encoding is None:
                encoding = sys.getdefaultencoding()
            bytes = text.encode(encoding, errors)
        else:
            # It is an error to specify an encoding if 'text' is
            # an 8-bit string.
            assert encoding is None

            if linesep is not None:
                text = (text.replace('\r\n', '\n')
                            .replace('\r', '\n'))
                bytes = text.replace('\n', linesep)

        self.write_bytes(bytes, append)

    def lines(self, encoding=None, errors='strict', retain=True):
        r""" Open this file, read all lines, return them in a list.

        Optional arguments:
            encoding - The Unicode encoding (or character set) of
                the file.  The default is None, meaning the content
                of the file is read as 8-bit characters and returned
                as a list of (non-Unicode) str objects.
            errors - How to handle Unicode errors; see help(str.decode)
                for the options.  Default is 'strict'
            retain - If true, retain newline characters; but all newline
                character combinations ('\r', '\n', '\r\n') are
                translated to '\n'.  If false, newline characters are
                stripped off.  Default is True.

        This uses 'U' mode.
        """
        if encoding is None and retain:
            with self.open('U') as f:
                return f.readlines()
        else:
            return self.text(encoding, errors).splitlines(retain)

    def write_lines(self, lines, encoding=None, errors='strict',
                    linesep=os.linesep, append=False):
        r""" Write the given lines of text to this file.

        By default this overwrites any existing file at this path.

        This puts a platform-specific newline sequence on every line.
        See 'linesep' below.

        lines - A list of strings.

        encoding - A Unicode encoding to use.  This applies only if
            'lines' contains any Unicode strings.

        errors - How to handle errors in Unicode encoding.  This
            also applies only to Unicode strings.

        linesep - The desired line-ending.  This line-ending is
            applied to every line.  If a line already has any
            standard line ending ('\r', '\n', '\r\n', u'\x85',
            u'\r\x85', u'\u2028'), that will be stripped off and
            this will be used instead.  The default is os.linesep,
            which is platform-dependent ('\r\n' on Windows, '\n' on
            Unix, etc.)  Specify None to write the lines as-is,
            like file.writelines().

        Use the keyword argument append=True to append lines to the
        file.  The default is to overwrite the file.  Warning:
        When you use this with Unicode data, if the encoding of the
        existing data in the file is different from the encoding
        you specify with the encoding= parameter, the result is
        mixed-encoding data, which can really confuse someone trying
        to read the file later.
        """
        if append:
            mode = 'ab'
        else:
            mode = 'wb'
        with self.open(mode) as f:
            for line in lines:
                isUnicode = isinstance(line, unicode)
                if linesep is not None:
                    # Strip off any existing line-end and add the
                    # specified linesep string.
                    if isUnicode:
                        if line[-2:] in (u'\r\n', u'\x0d\x85'):
                            line = line[:-2]
                        elif line[-1:] in (u'\r', u'\n',
                                           u'\x85', u'\u2028'):
                            line = line[:-1]
                    else:
                        if line[-2:] == '\r\n':
                            line = line[:-2]
                        elif line[-1:] in ('\r', '\n'):
                            line = line[:-1]
                    line += linesep
                if isUnicode:
                    if encoding is None:
                        encoding = sys.getdefaultencoding()
                    line = line.encode(encoding, errors)
                f.write(line)

    def read_md5(self):
        """ Calculate the md5 hash for this file.

        This reads through the entire file.
        """
        return self.read_hash('md5')

    def _hash(self, hash_name):
        with self.open('rb') as f:
            m = hashlib.new(hash_name)
            while True:
                d = f.read(8192)
                if not d:
                    break
                m.update(d)
            return m

    def read_hash(self, hash_name):
        """ Calculate given hash for this file.

        List of supported hashes can be obtained from hashlib package. This
        reads the entire file.
        """
        return self._hash(hash_name).digest()

    def read_hexhash(self, hash_name):
        """ Calculate given hash for this file, returning hexdigest.

        List of supported hashes can be obtained from hashlib package. This
        reads the entire file.
        """
        return self._hash(hash_name).hexdigest()



    #
    # Comme les fonctions, les méthodes peuvent être définies sur une ligne si
    # le bloc ne fait qu'une ligne de taille. On utilise ça quand la fonction
    # est juste un alias un peu avancé comme ici pour garder un style quasi
    # déclaratif.
    #

    # --- Methods for querying the filesystem.
    # N.B. On some platforms, the os.path functions may be implemented in C
    # (e.g. isdir on Windows, Python 3.2.2), and compiled functions don't get
    # bound. Playing it safe and wrapping them all in method calls.

    def isabs(self): return self.module.isabs(self)
    def exists(self): return self.module.exists(self)
    def isdir(self): return self.module.isdir(self)
    def isfile(self): return self.module.isfile(self)
    def islink(self): return self.module.islink(self)
    def ismount(self): return self.module.ismount(self)

    def samefile(self): return self.module.samefile(self)

    def getatime(self): return self.module.getatime(self)
    atime = property(
        getatime, None, None,
        """ Last access time of the file. """)

    def getmtime(self): return self.module.getmtime(self)
    mtime = property(
        getmtime, None, None,
        """ Last-modified time of the file. """)

    def getctime(self): return self.module.getctime(self)
    ctime = property(
        getctime, None, None,
        """ Creation time of the file. """)

    def getsize(self): return self.module.getsize(self)
    size = property(
        getsize, None, None,
        """ Size of the file, in bytes. """)

    #
    # Technique intéressante : on peut générer dynamiquement le corps de
    # la classe. En effet, il peut contenir des if, des try, des for, etc.
    # Ici par exemple, on ne définit la méthode access() que si le module
    # 'os' possède l'attribut 'access'.

    # Si ce n'est pas le cas, la classe n'aura pas cette méthode.
    #

    if hasattr(os, 'access'):
        def access(self, mode):
            """ Return true if current user has access to this path.

            mode - One of the constants os.F_OK, os.R_OK, os.W_OK, os.X_OK
            """
            return os.access(self, mode)

    def stat(self):
        """ Perform a stat() system call on this path. """
        return os.stat(self)

    def lstat(self):
        """ Like path.stat(), but do not follow symbolic links. """
        return os.lstat(self)


    #
    # Une autre technique intéressante : une des rares utilisation du double
    # '_' en tant que préfixe qui ait du sens. '__method' interdit d'accéder
    # directement à la méthode depuis l'extérieur. C'est ce qu'on a de plus
    # proche de "private" en Python.

    # Ce n'est pas sécurisé du tout (on peut le contourner) et cela empêche le
    # monkey patching et autres mesures de contournement en cas de besoin,
    # donc je ne vous recommande pas de le faire.

    # Mais dans ce cas, ces méthodes sont volontairement définies ainsi pour
    # être invisibles puis un peu plus bas, si win32security ou pwd existent
    # (rappelez-vous, ce sont des dépendances optionnelles), alors elles sont
    # aliasées pour être rendues disponibles.

    # Il y a 3 implémentations (3 méthodes: une pour windows, une pour unix et
    # une pour le cas où aucun module n'est présent) pour la même
    # fonctionnalité, et l'une des 3 méthodes est utilisée comme
    # implémentation de get_owner().

    # On aurait pu tout mettre dans des if directement, mais ça ferait des
    # gros blocs moins lisibles. Ici il est facile de comprendre le code
    # source.
    #

    def __get_owner_windows(self):
        r"""
        Return the name of the owner of this file or directory. Follow
        symbolic links.

        Return a name of the form ur'DOMAIN\User Name'; may be a group.
        """
        desc = win32security.GetFileSecurity(
            self, win32security.OWNER_SECURITY_INFORMATION)
        sid = desc.GetSecurityDescriptorOwner()
        account, domain, typecode = win32security.LookupAccountSid(None, sid)
        return domain + u'\\' + account

    def __get_owner_unix(self):
        """
        Return the name of the owner of this file or directory. Follow
        symbolic links.
        """
        st = self.stat()
        return pwd.getpwuid(st.st_uid).pw_name

    def __get_owner_not_implemented(self):
        raise NotImplementedError("Ownership not available on this platform.")

    if 'win32security' in globals():
        get_owner = __get_owner_windows
    elif 'pwd' in globals():
        get_owner = __get_owner_unix
    else:
        get_owner = __get_owner_not_implemented

    owner = property(
        get_owner, None, None,
        """ Name of the owner of this file or directory. """)

    if hasattr(os, 'statvfs'):
        def statvfs(self):
            """ Perform a statvfs() system call on this path. """
            return os.statvfs(self)

    if hasattr(os, 'pathconf'):
        def pathconf(self, name):
            return os.pathconf(self, name)


    #
    # Pas d'autres commentaires après celui-là. jusqu'à la classe de fin.

    # Les méthodes suivantes retournent 'self' bien que ce ne soit
    # pas nécessaire.
    # Par exemple path('/tmp/test').chmod(777) va retourner path('/tmp/test')
    # alors que tout ce qu'on lui demande, c'est de changer la permission
    # du dossier. On le fait pour permettre le chaîning, c'est à dire
    # d'autoriser les appels enchainés comme :
    # path('/tmp/test').chmod(777).rename('/tmp/essai').mkdir('ping')
    #

    #
    # --- Modifying operations on files and directories

    def utime(self, times):
        """ Set the access and modified times of this file. """
        os.utime(self, times)
        return self

    def chmod(self, mode):
        os.chmod(self, mode)
        return self

    if hasattr(os, 'chown'):
        def chown(self, uid, gid):
            os.chown(self, uid, gid)
            return self

    def rename(self, new):
        os.rename(self, new)
        return self._next_class(new)

    def renames(self, new):
        os.renames(self, new)
        return self._next_class(new)

    #
    # --- Create/delete operations on directories

    def mkdir(self, mode=0777):
        os.mkdir(self, mode)
        return self

    def mkdir_p(self, mode=0777):
        try:
            self.mkdir(mode)
        except OSError, e:
            if e.errno != errno.EEXIST:
                raise
        return self

    def makedirs(self, mode=0777):
        os.makedirs(self, mode)
        return self

    def makedirs_p(self, mode=0777):
        try:
            self.makedirs(mode)
        except OSError, e:
            if e.errno != errno.EEXIST:
                raise
        return self

    def rmdir(self):
        os.rmdir(self)
        return self

    def rmdir_p(self):
        try:
            self.rmdir()
        except OSError, e:
            if e.errno != errno.ENOTEMPTY and e.errno != errno.EEXIST:
                raise
        return self

    def removedirs(self):
        os.removedirs(self)
        return self

    def removedirs_p(self):
        try:
            self.removedirs()
        except OSError, e:
            if e.errno != errno.ENOTEMPTY and e.errno != errno.EEXIST:
                raise
        return self

    # --- Modifying operations on files

    def touch(self):
        """ Set the access/modified times of this file to the current time.
        Create the file if it does not exist.
        """
        fd = os.open(self, os.O_WRONLY | os.O_CREAT, 0666)
        os.close(fd)
        os.utime(self, None)
        return self

    def remove(self):
        os.remove(self)
        return self

    def remove_p(self):
        try:
            self.unlink()
        except OSError, e:
            if e.errno != errno.ENOENT:
                raise
        return self

    def unlink(self):
        os.unlink(self)
        return self

    def unlink_p(self):
        self.remove_p()
        return self

    # --- Links

    if hasattr(os, 'link'):
        def link(self, newpath):
            """ Create a hard link at 'newpath', pointing to this file. """
            os.link(self, newpath)
            return self._next_class(newpath)

    if hasattr(os, 'symlink'):
        def symlink(self, newlink):
            """ Create a symbolic link at 'newlink', pointing here. """
            os.symlink(self, newlink)
            return self._next_class(newlink)

    if hasattr(os, 'readlink'):
        def readlink(self):
            """ Return the path to which this symbolic link points.

            The result may be an absolute or a relative path.
            """
            return self._next_class(os.readlink(self))

        def readlinkabs(self):
            """ Return the path to which this symbolic link points.

            The result is always an absolute path.
            """
            p = self.readlink()
            if p.isabs():
                return p
            else:
                return (self.parent / p).abspath()

    #
    # --- High-level functions from shutil

    copyfile = shutil.copyfile
    copymode = shutil.copymode
    copystat = shutil.copystat
    copy = shutil.copy
    copy2 = shutil.copy2
    copytree = shutil.copytree
    if hasattr(shutil, 'move'):
        move = shutil.move
    rmtree = shutil.rmtree

    def rmtree_p(self):
        try:
            self.rmtree()
        except OSError, e:
            if e.errno != errno.ENOENT:
                raise
        return self

    #
    # --- Special stuff from os

    if hasattr(os, 'chroot'):
        def chroot(self):
            os.chroot(self)

    if hasattr(os, 'startfile'):
        def startfile(self):
            os.startfile(self)
            return self


#
# La seule spécificité de cette classe est d'overrider la méthode __new__ qui
# est le véritable constructeur en Python (__init__ n'est pas un constructeur)
# L'auteur le fait car tempdir hérite de path qui hérite d'unicode. Or, tous
# les types non-mutables (int, tuple, str, etc, et donc unicode), n'étant pas
# modifiables, ne peuvent être changés dans __init__. Ici __new__ est
# utilisé pour retourner un path tout en créant un dossier temporaire, ce
# qui ne marcherait pas dans __init__. Il est très rare d'avoir besoin de
# s'occuper de __new__.
#

class tempdir(path):
    """
    A temporary directory via tempfile.mkdtemp, and constructed with the
    same parameters that you can use as a context manager.

    Example:

        with tempdir() as d:
            # do stuff with the path object "d"

        # here the directory is deleted automatically
    """

    @ClassProperty
    @classmethod
    def _next_class(cls):
        return path

    def __new__(cls, *args, **kwargs):
        dirname = tempfile.mkdtemp(*args, **kwargs)
        return super(tempdir, cls).__new__(cls, dirname)

    def __init__(self, *args, **kwargs):
        pass

    def __enter__(self):
        return self

    def __exit__(self, exc_type, exc_value, traceback):
        if not exc_value:
            self.rmtree()

C’est une bibliothèque très complète et propre, et bien qu’il y ait quelques astuces ici et là, vous avez pu constater que l’usage de la POO reste tout à fait accessible : héritage simple, déclaration de méthode, properties, etc. On ne fait pas beaucoup de folies.

Il n’y a pas besoin de faire les choses compliquées avec la POO, on peut faire des choses tout à fait ordinaires et utiles.

Pour le dernier tuto de la série, on tapera dans la magie noire, à savoir les métaclasses. Tintintin.

P.S: cet article a été sponsorisé par le plugin Sublime Text Wraps Plus. Avec Wraps Plus, plus de caractères en sus !