Sam & Max » poo http://sametmax.com Du code, du cul Sat, 07 Nov 2015 10:56:13 +0000 en-US hourly 1 http://wordpress.org/?v=4.1 A propos des attributs préfixés de deux underscores 2 http://sametmax.com/a-propos-des-attributs-prefixes-de-deux-underscores/ http://sametmax.com/a-propos-des-attributs-prefixes-de-deux-underscores/#comments Fri, 03 Jul 2015 08:18:29 +0000 http://sametmax.com/?p=16556 il n'y a pas d'attributs privés au sens propre, uniquement une convention disant que tout ce qu'on préfixe d'un underscore ne fait pas partie de l'API publique.]]> En Python, il n’y a pas d’attributs privés au sens propre, uniquement une convention disant que tout ce qu’on préfixe d’un underscore ne fait pas partie de l’API publique.

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)
<ipython-input-5-225402ba2794> in <module>()
----> 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.

]]>
http://sametmax.com/a-propos-des-attributs-prefixes-de-deux-underscores/feed/ 2
Je n’expliquerai plus les CBV 17 http://sametmax.com/je-nexpliquerai-plus-les-cbv/ http://sametmax.com/je-nexpliquerai-plus-les-cbv/#comments Mon, 11 May 2015 11:42:49 +0000 http://sametmax.com/?p=16221 Les Class Based Views sont des vues génériques réutilisables qui permettent de faire automatiquement des tâches courantes dans Django comme :

  • 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.

]]>
http://sametmax.com/je-nexpliquerai-plus-les-cbv/feed/ 17
Attributs privés en Python 8 http://sametmax.com/variables-privees-en-python/ http://sametmax.com/variables-privees-en-python/#comments Sat, 21 Jun 2014 01:15:00 +0000 http://sametmax.com/?p=11050 Tout est accessible en Python. Il n'y a pas de variables privées.]]> Tout est accessible en Python. Il n’y a pas de variables privées.

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.

]]>
http://sametmax.com/variables-privees-en-python/feed/ 8
Mais qui donc hérite de ma classe ? 6 http://sametmax.com/mais-qui-donc-herite-de-ma-classe/ http://sametmax.com/mais-qui-donc-herite-de-ma-classe/#comments Fri, 20 Jun 2014 13:39:23 +0000 http://sametmax.com/?p=11013 Pas une question que l’on se pose souvent, à moins d’avoir une lib qui expose une classe avec beaucoup d’introspection.

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
## <type 'callable-iterator'>
## <class '_abcoll.Sized'>
## <type 'exceptions.EOFError'>
## <class '_abcoll.Mapping'>
## <type 'exceptions.UnicodeWarning'>
## <type 'exceptions.IOError'>
## <type 'memoryview'>
## <type 'code'>
## <type 'exceptions.ImportWarning'>
## <type 'sys.flags'>
## <type 'iterator'>
## <class 'warnings.catch_warnings'>
## <type 'exceptions.Warning'>
## <type 'exceptions.EnvironmentError'>
## <type 'dict'>
## <class 'encodings.utf_8.IncrementalEncoder'>
## <type 'weakproxy'>
## <class '_abcoll.Iterator'>
## <type 'sys.version_info'>
## <type 'posix.stat_result'>
## <type 'frozenset'>
## <class 'codecs.CodecInfo'>
## <class 'zipimport.ZipImportError'>
## <type 'exceptions.StopIteration'>
## <type 'exceptions.ImportError'>
## <class 'site._Printer'>
## <type 'weakref'>
## <class '_abcoll.Sequence'>
## <type 'property'>
## <class 'encodings.utf_8.IncrementalDecoder'>
## <type 'imp.NullImporter'>
## <type 'exceptions.TypeError'>
## <type 'bytearray'>
## <type 'int'>
## <type 'exceptions.UnicodeTranslateError'>
## <type 'instance'>
## <type 'exceptions.BaseException'>
## <type 'exceptions.SyntaxWarning'>
## <type 'file'>
## <class '_abcoll.MappingView'>
## <class '_weakrefset._IterationGuard'>
## <type 'exceptions.UnicodeDecodeError'>
## <type 'classobj'>
## <type 'exceptions.UnicodeError'>
## <class 'abc.abstractproperty'>
## <type 'exceptions.DeprecationWarning'>
## <type 'complex'>
## <type 'set'>
## <type 'buffer'>
## <type 'generator'>
## <type 'exceptions.Exception'>
## <class 'codecs.IncrementalDecoder'>
## <type 'exceptions.UserWarning'>
## <type 'staticmethod'>
## <type 'exceptions.UnicodeEncodeError'>
## <class 'encodings.CodecRegistryError'>
## <class '_abcoll.MutableSequence'>
## <class '_abcoll.KeysView'>
## <type 'cell'>
## <type 'exceptions.StandardError'>
## <type 'enumerate'>
## <type 'exceptions.KeyboardInterrupt'>
## <type 'exceptions.BufferError'>
## <class 'warnings.WarningMessage'>
## <type 'EncodingMap'>
## <class 'codecs.BufferedIncrementalDecoder'>
## <type 'exceptions.ValueError'>
## <class '_abcoll.Set'>
## <type 'exceptions.MemoryError'>
## <type 'exceptions.SystemExit'>
## <type 'reversed'>
## <class '_abcoll.Hashable'>
## <type 'bool'>
## <type 'classmethod'>
## <type 'exceptions.ReferenceError'>
## <type 'exceptions.GeneratorExit'>
## <class '_abcoll.Container'>
## <class '_abcoll.ItemsView'>
## <type 'xrange'>
## <type 'exceptions.PendingDeprecationWarning'>
## <type 'basestring'>
## <type 'exceptions.SystemError'>
## <type 'exceptions.ZeroDivisionError'>
## <class 'site.Quitter'>
## <type 'long'>
## <type 'NotImplementedType'>
## <type 'super'>
## <type 'fieldnameiterator'>
## <class '_abcoll.Callable'>
## <class '_abcoll.MutableSet'>
## <type 'exceptions.ArithmeticError'>
## <class 'abc.ABCMeta'>
## <type 'exceptions.OverflowError'>
## <type 'exceptions.FutureWarning'>
## <type 'sys.float_info'>
## <type 'formatteriterator'>
## <type 'type'>
## <type 'exceptions.AssertionError'>
## <type 'traceback'>
## <type 'exceptions.FloatingPointError'>
## <type 'function'>
## <type 'instancemethod'>
## <type 'sys.long_info'>
## <type 'builtin_function_or_method'>
## <class 'signal.ItimerError'>
## <class 'site._Helper'>
## <type 'exceptions.LookupError'>
## <type 'wrapper_descriptor'>
## <type 'exceptions.KeyError'>
## <class '_abcoll.ValuesView'>
## <type 'slice'>
## <class '_weakrefset.WeakSet'>
## <type 'list'>
## <type 'exceptions.IndexError'>
## <type 'getset_descriptor'>
## <type 'posix.statvfs_result'>
## <type 'exceptions.SyntaxError'>
## <type 'frame'>
## <class 'codecs.BufferedIncrementalEncoder'>
## <type 'PyCapsule'>
## <type 'exceptions.IndentationError'>
## <type 'NoneType'>
## <type 'zipimport.zipimporter'>
## <type 'member_descriptor'>
## <type 'exceptions.AttributeError'>
## <type 'ellipsis'>
## <type 'exceptions.UnboundLocalError'>
## <type 'unicode'>
## <class '_abcoll.Iterable'>
## <type 'exceptions.TabError'>
## <type 'exceptions.NameError'>
## <type 'tuple'>
## <class 'warnings._OptionError'>
## <type 'exceptions.NotImplementedError'>
## <type 'exceptions.RuntimeWarning'>
## <type 'str'>
## <class '_abcoll.MutableMapping'>
## <type 'exceptions.BytesWarning'>
## <type 'module'>
## <type 'exceptions.RuntimeError'>
## <class 'codecs.IncrementalEncoder'>
## <type 'float'>
## <type 'exceptions.OSError'>
## <type 'dictproxy'>
## <type 'weakcallableproxy'>

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

]]>
http://sametmax.com/mais-qui-donc-herite-de-ma-classe/feed/ 6
Le dossier sur la POO fait peau neuve 11 http://sametmax.com/le-dossier-sur-la-poo-fait-peau-neuve/ http://sametmax.com/le-dossier-sur-la-poo-fait-peau-neuve/#comments Thu, 27 Feb 2014 10:03:24 +0000 http://sametmax.com/?p=9629 Je me répète, mais on doit énormément aux relecteurs sur ce blog. Ils ne font pas de bruit, mais ils passent derrière, tels des nettoyeurs de scènes de crimes sur notre prose sanglante.

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)

]]>
http://sametmax.com/le-dossier-sur-la-poo-fait-peau-neuve/feed/ 11
Ecrire un code pour les autres en Python 10 http://sametmax.com/ecrire-un-code-pour-les-autres-en-python/ http://sametmax.com/ecrire-un-code-pour-les-autres-en-python/#comments Sat, 17 Aug 2013 13:15:07 +0000 http://sametmax.com/?p=7122 Cet article s’adresse à des développeurs qui commencent à être bien dans leurs chaussettes en Python et qui se sentent de relever le défi d’écrire du code pour d’autres personnes.

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

]]>
http://sametmax.com/ecrire-un-code-pour-les-autres-en-python/feed/ 10
Objets proxy et pattern adapter en Python 11 http://sametmax.com/objets-proxy-et-pattern-adapter-en-python/ http://sametmax.com/objets-proxy-et-pattern-adapter-en-python/#comments Fri, 16 Aug 2013 19:40:02 +0000 http://sametmax.com/?p=7112 En informatique, le vocabulaire c’est une bonne partie du travail. On a des tas de termes comme polymorphisme, récursivité, idempotent ou closure. Certains sont des termes mathématiques, d’autres sont des anglicismes, mais la majorité sont juste des mots compliqués pour décrire des choses simples.

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 "<ipython-input-23-6d509f016e40>", line 1, in <module>
    prof.demande_autorisation_de_sortie(enfant)
  File "<ipython-input-18-e8d34178df4c>", line 4, in demande_autorisation_de_sortie
    return enfant.peut_sortir()
  File "<ipython-input-18-e8d34178df4c>", 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.

]]>
http://sametmax.com/objets-proxy-et-pattern-adapter-en-python/feed/ 11
Le guide ultime et définitif sur la programmation orientée objet en Python à l’usage des débutants qui sont rassurés par les textes détaillés qui prennent le temps de tout expliquer. Partie 8. 21 http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-8/ http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-8/#comments Tue, 02 Jul 2013 07:31:26 +0000 http://sametmax.com/?p=6524 8ème et dernier chapitre sur la programmation orientée objet en Python. Nous allons voir l’ultime réalité, le secret cosmique de nirvana Pythonique, le truc dont personne ne se sert avant d’avoir au moins codé 3 moteurs de blogs, un bot twitter et une IA de real doll.

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 <class '__main__.CreateurDObject'>

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
<type 'type'>
>>> nouveau_pokemon = Pokemon() # la je crée une instance
>>> type(nouveau_pokemon)
<class '__main__.Salameche'>

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)
<type 'int'>
>>> print type("1")
<type 'str'>
>>> print type(CreateurDObject)
<type 'type'>
>>> print type(CreateurDObject())
<class '__main__.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)
<class '__main__.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__
<type 'int'>
>>> nom = 'magicarp'
>>> nom.__class__
<type 'str'>
>>> def attrapez_les_presque_tous(): pass
>>> attrapez_les_presque_tous.__class__
<type 'function'>
>>> class Pokedex(object): pass
>>> gadget = Pokedex()
>>> gadget.__class__
<class '__main__.Pokedex'>

Mais quelle est le __class__ de tout __class__ ?

>>> attrapez_les_presque_tous.__class__.__class__
<type 'type'>
>>> pokemon_capture.__class__.__class__
<type 'type'>
>>> nom.__class__.__class__
<type 'type'>
>>> gadget.__class__.__class__
<type 'type'>

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 "<ipython-input-58-90dd54234d5d>", line 1, in <module>
    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 "<ipython-input-66-90dd54234d5d>", line 1, in <module>
    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__
<type 'type'>

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

]]>
http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-8/feed/ 21
Le guide ultime et définitif sur la programmation orientée objet en Python à l’usage des débutants qui sont rassurés par les textes détaillés qui prennent le temps de tout expliquer. Partie 7. 24 http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-7/ http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-7/#comments Sun, 28 Apr 2013 05:47:17 +0000 http://sametmax.com/?p=5912 path.py.]]> Un peu de rock à l’anglaise pour faire passer la pilule :

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.

 
#<sm>
# 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.
#</sm>
 
#
# 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.
#
 
#<sm>
# 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.
#</sm>
 
 
""" path.py - An object representing a path to a file or directory.
 
Original author:
 Jason Orendorff <jason.orendorff\x40gmail\x2ecom>
 
Current maintainer:
 Jason R. Coombs <jaraco@jaraco.com>
 
Contributors:
 Mikhail Gusarov <dottedmag@dottedmag.net>
 Marc Abramowitz <marc@marc-abramowitz.com>
 Jason R. Coombs <jaraco@jaraco.com>
 Jason Chu <jchu@xentac.net>
 Vojislav Stojkovic <vstojkovic@syntertainment.com>
 
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.
"""
 
 
#<sm>
# 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__
#</sm>
from __future__ import with_statement
 
import sys #<sm>Informations sur le système</sm>
import warnings #<sm>Alertes techniques à d'autres dev</sm>
import os #<sm>Manipulation du File System</sm>
import fnmatch #<sm>Pattern matching comme dans un shell</sm>
import glob #<sm>Lister des fichier avec la syntax shell</sm>
import shutil #<sm>Manipulation de fichiers de haut niveau</sm>
import codecs #<sm>Encoding</sm>
import hashlib #<sm>Sommes de contrôle</sm>
import errno #<sm>Les codes d'erreurs liées aux fichiers.</sm>
import tempfile #<sm>Création de fichiers temporaires</sm>
import functools #<sm>Manipulation des fonctions</sm>
 
#<sm>
# 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.
#</sm>
try:
    import win32security
except ImportError:
    pass
 
try:
    import pwd
except ImportError:
    pass
 
 
 
#<sm>
# 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é.
#</sm>
__version__ = '3.0'
__all__ = ['path']
 
 
#<sm>
# 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.
#</sm>
 
 
class TreeWalkWarning(Warning):
    pass
 
 
#<sm>
# 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.
 
#</sm>
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
 
 
#<sm>
# 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.
#</sm>
class ClassProperty(property):
    def __get__(self, cls, owner):
        return self.fget.__get__(None, owner)()
 
#<sm>
# 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 :-)
#</sm>
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)
        )
 
 
#<sm>
# 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.
#</sm>
class path(unicode):
    """ Represents a filesystem path.
 
    For documentation on individual methods, consult their
    counterparts in os.path.
    """
 
    #<sm>
    # 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.
    #</sm>
 
    def __init__(self, other):
        if not isinstance(other, basestring):
            raise TypeError("path must be a string")
 
    #<sm>
    # 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.
 
    #</sm>
 
    module = os.path
    "The path module to use for path operations."
 
 
    #<sm>
    # 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.
 
    #</sm>
    @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)
 
 
    #<sm>
    # 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.
    #</sm>
    @ClassProperty
    @classmethod
    def _next_class(cls):
        """
        What class should be used to construct new instances from this class
        """
        return cls
 
    # --- Special Python methods.
 
    #<sm>
    # 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.
    #</sm>
 
 
    #<sm>
    # 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().
    #</sm>
    def __repr__(self):
        return '%s(%s)' % (type(self).__name__, super(path, self).__repr__())
 
 
    #<sm>
    # Override l'addition.
    # path('truc') + 'machin' donne path('trucmachin')
    #</sm>
    # 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
 
    #<sm>
    # 'machin' + path('truc') donne path('trucmachin')
    #</sm>
    def __radd__(self, other):
        if not isinstance(other, basestring):
            return NotImplemented
        return self._next_class(other.__add__(self))
 
    #<sm>
    # Override la division.
    # path('truc') / 'machin' donne path('truc/machin')
    #</sm>
    # 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))
 
    #<sm>
    # 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.
    #</sm>
 
    # Make the / operator work even when true division is enabled.
    __truediv__ = __div__
 
    #<sm>
    # 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.
    #</sm>
    def __enter__(self):
        self._old_dir = self.getcwd()
        os.chdir(self)
 
    def __exit__(self, *_):
        os.chdir(self._old_dir)
 
 
    #<sm>
    # 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.
    #</sm>
 
    @classmethod
    def getcwd(cls):
        """ Return the current working directory as a path object. """
        return cls(os.getcwdu())
 
    #
    # --- Operations on path strings.
 
    #<sm>
    # 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')
    #</sm>
 
    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))
 
 
    #<sm>
    # 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.
    #</sm>
 
    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()
 
 
    #<sm>
    # 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.
    #</sm>
 
    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)
 
 
    #<sm>
 
    # 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.
 
    #</sm>
 
    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.
        """)
 
    #<sm>
    # 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().
    #</sm>
 
    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, <the rest of p>).
 
        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
 
    #<sm>
    # 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.
    #</sm>
 
    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)
 
    #<sm>
    # 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
    #</sm>
 
    @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))
 
 
    #<sm>
    # 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.
 
    #</sm>
 
    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
 
 
    #<sm>
 
    # 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
 
    #</sm>
 
    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
 
    #<sm>
    # 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.
    #</sm>
 
    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]
 
    #<sm>
    # 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.
 
    #</sm>
 
    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()]
 
 
    #<sm>
 
    # 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.
 
    #</sm>
 
    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)
 
    #<sm>
 
    # 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.
 
    #</sm>
 
 
    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'))
 
    #<sm>
    # 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.
    #</sm>
 
    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()
 
 
 
    #<sm>
    # 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.
    #</sm>
 
    # --- 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. """)
 
    #<sm>
    # 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.
    #</sm>
 
    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)
 
 
    #<sm>
    # 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.
    #</sm>
 
    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)
 
 
    #<sm>
    # 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')
    #</sm>
 
    #
    # --- 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
 
 
#<sm>
# 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__.
#</sm>
 
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 !

]]>
http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-7/feed/ 24
Le guide ultime et définitif sur la programmation orientée objet en Python à l’usage des débutants qui sont rassurés par les textes détaillés qui prennent le temps de tout expliquer. Partie 5. 58 http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-5/ http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-5/#comments Mon, 11 Feb 2013 17:38:28 +0000 http://sametmax.com/?p=4495 Maestro, musique !

Prérequis :

La POO, c’est comme les poupées russes. Une fois qu’on a maîtrisé un concept, paf, y en a un autre qui se ramène derrière.

J’ai plusieurs mamans

En ces temps de polémique sur l’autorisation du mariage entre êtres amoureux et consentants (par opposition à celui qu’on fait par convention sociale depuis des siècles), je vous propose de vous rappeler qu’une fois de plus les informaticiens sont en avance sur les mœurs.

D’abord parce qu’une communauté qui fait autant de links vers Never Gona Give You Up est forcément pro gay par essence. Ensuite parce qu’une classe fille peut avoir plusieurs classes mères sans que ça choque personne.

Prenez ces deux classes qui passaient par là sans rien demander :

class MouMoutte(object):
 
    type = 'top' # c'est tip top moumoutte
 
class Raoul(object):
 
    trop = 'cool'

Hé merde, j’ai écris ça, et maintenant j’ai aucune idée de comment faire un code cohérent à partir de cet exemple à la con.

On annule tout.

On recommence.

Vous faites un jeu vidéo. Ça, ça parle bien. Et dedans vous avez des protections et des armes.

class Arme(object):
 
    def __init__(self, nom, degat):
 
        self.nom = nom
        self.degat = degat
 
    def attaque(self, cible): # on retire les degâts de l'épee des points de vie
        cible.vie -= self.degat
 
 
class Protection(object):
 
    def __init__(self, nom, armure):
 
        self.nom = nom
        self.armure = armure
 
    def defend(self, degat): # on diminue les degâts, voire on les annule
 
        degat = degat - self.armure
        if degat < 0:
            return 0
 
        return degat
 
>>> epee = Arme('Epée Mana', degat=999)
>>> casque = Protection('Casque de Balduran', armure=1)

C’est simpliste, mais vous voyez le tableau. Maintenant un connard de client arrive et vous sort une idée trop cool : il faudrait ajouter un barbare dans le jeu. Qui tape aussi avec son bouclier, parce que la concurrence le fait et qu’ils veulent pas se faire mettre un vent par Blizzard.

Enfer et Rutabaga ! Comment allons nous nous sortir de cette situation ?

Il y a moult manières de faire, mais l’une d’elle est d’utiliser l’héritage multiple, c’est-à-dire de créer une classe qui hérite des deux classes en même temps.

class ProtectionOffensive(Arme, Protection):
 
    def __init__(self, nom, degat, armure):
 
        Arme.__init__(self, nom, degat) # appelle le __init__ de arme
        Protection.__init__(self, nom, armure) # appelle le __init de protection
 
        # comme on a appelé les deux __init__, on va avoir les attributs
        # settés dans les deux __init__ attachés à cette classe

Nous avons alors une classe qui possède les méthodes des deux classes parentes :

>>> bouclier = ProtectionOffensive('Bouclier du dragon', degat=10, armure=100)
>>> bouclier.degat
10
>>> bouclier.armure
100
>>> bouclier.defend(10)
0

Ne cherchez pas compliqué, ça fait exactement ce que ça à l’air de faire : “copier” (oui bon, entre guillemets) le code de chaque parent dans l’enfant.

Néanmoins vous avez vu qu’il y a quelques subtilités, notamment la partie __init__.

Posez-vous deux minutes. Respirez. Concentrez-vous. Prêt ?

Les deux classes parentes ont une méthode __init__, mais Python ne peut en “copier” qu’une seule dans l’enfant. Il copie donc la première qu’il trouve. Il va prendre la liste des parents (ici: Arme, Protection), et la lire de gauche à droite. Il va regarder chaque parent, et si la méthode existe, il va la “copier” dans l’enfant.

Si il retrouve une méthode de même nom dans un des parents suivants, il l’ignore. (Je dis un DES parents suivants car vous pouvez avoir 10 parents si vous voulez).

Donc dans notre exemple, si je fais :

class ProtectionOffensive(Arme, Protection):
    pass

ProtectionOffensive n’aura que la méthode __init__ de Arme. Or ce n’est pas ce qu’on veut. On va donc overrider la méthode __init__, et dedans appeler la méthode __init__ de Arme ET celle de Protection.

Cette syntaxe : Classe.methode(self, args...) que l’on retrouve dans Arme.__init__(self, nom, degat) est juste un moyen d’appeler spécifiquement la méthode du parent.

Dans la partie précédente, je vous ai montré qu’on pouvait faire cela avec super(). Or super() vous retournera la première méthode du premier parent qu’elle trouve : c’est le but de super(), de faire ça automatiquement sans se soucier de savoir qui est le premier parent à avoir une méthode du bon nom.

C’est utile car parfois c’est le parent du parent du parent qui a la méthode qu’on veut appeler. On ne connaît pas forcément son nom, ou alors on ne veut pas l’écrire en dur. Mais dans notre cas, on veut spécifiquement une méthode d’un parent en particulier, il faut donc l’écrire à la main.

D’une manière générale :

  • Utilisez super() quand vous faites de l’héritage simple où que vous voulez juste appeler la méthode du premier parent venu sans vous soucier de son nom (car il peut être très haut dans la chaîne d’héritage).
  • Utilisez Classe.methode(self, args...) quand vous voulez spécifiquement appeler la méthode d’un parent en particulier.

Faites attention !

Le self n’est pas au même endroit dans super(ClassCourante, self).methode(args...) et ClasseParente.methode(self, args...). Et dans le premier cas, on passe la classe courante (que super() va analyser pour trouver les parents automatiquement), dans le cas suivant, on écrit le nom de la classe parente en dur.

Faites quelques tests avec des scripts bidons pour bien comprendre comment ça marche. Faites ça avec des classes toutes simples. Sinon le jour où vous aurez une classe compliquée, vous allez vous embrouiller.

La composition (POO pour les vrais mecs)

Jusqu’ici c’était un tuto avec des notions de base pour des petits geeks imberbes qui jouent avec des action figures fabriquées en Chine et achetées sur ebay. Mais maintenant nous allons voir la POO pour les vrais hommes, les barbus, ceux qui jouent avec des reals dolls et qui n’ont pas peur de mettre des chaussettes dépareillées.

Voyez-vous, un objet, tout seul, il sert à rien. Il s’emmerde déjà, rien à foutre le samedi, nul part où sortir, tout ça. Mais surtout, il a personne pour prendre l’apéro. Non, dans un programme digne d’un vrai pastis, il faut plusieurs objets qui interagissent entre eux. En fait, plusieurs objets qui s’utilisent les uns les autres.

Retournez à notre exemple de jeu video :

class HeroViril(object):
 
    # def __init__(self, nom, prenom, groupe_sanguin, signe_astrologique,
    #              couleur_preferee, tendance_sexuelle, culte,
    #              taille_de_la_troisieme_phallange_de_l_index_gauche)
    # TODO : voir le CDC avec le client pour confirmer les attributs du personnage
    def __init__(self, nom, vie, arme=None, protection=None):
 
        self.nom = nom
        self.vie = vie
        self.arme = arme
        self.protection = protection
 
    def combattre(self, ennemi):
 
        print "{} attaque {}".format(self.nom, ennemi.nom)
 
        while True:
 
            if self.arme:
                self.arme.attaque(ennemi)
 
            if ennemi.vie <= 0:
                break
 
            if ennemi.arme:
                ennemi.arme.attaque(self)
 
            if self.vie <= 0:
                break
 
        if self.vie > 0:
            print "Victoire de {}".format(self.nom)
        else:
            print "{} est mort comme une pov' merde".format(self.nom)

Et là vous notez un truc, c’est que nous n’avons pas de méthode attaque() sur notre héros. Nous utilisons la méthode attaque d’un objet arme. Que l’on a en attribut.

C’est cela la composition : un objet, qui en fait est composé de plusieurs sous-objets. Dans notre cas, notre objet héros est aussi composé d’une arme et d’une protection, qui sont ses attributs. Il peut ainsi utiliser le comportement de ses objets pour faire le boulot à sa place : c’est ce qu’on appelle la délégation.

Reprenons notre code des armes, un peu adapté :

# le code de l'armure ne change pas
class Protection(object):
 
    def __init__(self, nom, armure):
 
        self.nom = nom
        self.armure = armure
 
    def defend(self, degat):
 
        degat = degat - self.armure
        if degat < 0:
            return 0
 
        return degat
 
 
# on change le code de l'arme, si la cible a une protection
# cela diminue les degâts pris
class Arme(object):
 
    def __init__(self, nom, degat):
 
        self.nom = nom
        self.degat = degat
 
    def attaque(self, cible):
 
        # je mets aussi quelques prints pour le lulz
        if cible.protection:
            degat = cible.protection.defend(self.degat)
            print "{} - {} = {}".format(cible.vie, degat, cible.vie - degat)
            cible.vie -= degat
        else:
            print "{} - {} = {}".format(cible.vie, self.degat, cible.vie - self.degat)
            cible.vie -= self.degat

Maintenant créons deux héros, armons-les, et faisons-les combattre :

>>> gosu = HeroViril("Drizzt Do'Urden", 2000)
>>> gosu.arme = Arme('Lame Vorpale', 10)
>>> gosu.protection = Protection("Maille en Kevlar de mithril doré a l'adamantium", 10)
>>> noob_qui_repop = HeroViril("Bob", 200)
>>> noob_qui_repop.arme = Arme('Cure-dent', 1)
>>> noob_qui_repop.protection = Protection("Slip", 1)
>>> noob_qui_repop.combattre(gosu) # yaaaaaaaaaaaaaaaaaaaaaaa !
 
Bob attaque Drizzt Do'Urden
2000 - 0 = 2000
200 - 9 = 191
2000 - 0 = 2000
191 - 9 = 182
2000 - 0 = 2000
182 - 9 = 173
2000 - 0 = 2000
173 - 9 = 164
2000 - 0 = 2000
164 - 9 = 155
2000 - 0 = 2000
155 - 9 = 146
2000 - 0 = 2000
146 - 9 = 137
2000 - 0 = 2000
137 - 9 = 128
2000 - 0 = 2000
128 - 9 = 119
2000 - 0 = 2000
119 - 9 = 110
2000 - 0 = 2000
110 - 9 = 101
2000 - 0 = 2000
101 - 9 = 92
2000 - 0 = 2000
92 - 9 = 83
2000 - 0 = 2000
83 - 9 = 74
2000 - 0 = 2000
74 - 9 = 65
2000 - 0 = 2000
65 - 9 = 56
2000 - 0 = 2000
56 - 9 = 47
2000 - 0 = 2000
47 - 9 = 38
2000 - 0 = 2000
38 - 9 = 29
2000 - 0 = 2000
29 - 9 = 20
2000 - 0 = 2000
20 - 9 = 11
2000 - 0 = 2000
11 - 9 = 2
2000 - 0 = 2000
2 - 9 = -7
Bob est mort comme une pov' merde

Ok, j’ai pigé le principe, mais comment ça marche dans le détail ?

Regardons la méthode combattre de plus près :

    # elle attend un ennemi en paramètre, donc UN OBJET HeroViril
    # self est l'objet en cours, donc aussi un objet HeroViril
    def combattre(self, ennemi):
 
        print "{} attaque {}".format(self.nom, ennemi.nom)
 
        # une petite boucle infinie. Warning, c'est un tuto. Ne faites pas
        # ça chez vous les enfants.
        # cette boucle loop pour toujours si il n'y a pas d'attribut arme donc
        # ceci n'est qu'un exemple. Hein ? Noté ? Les deux du fond là ?
        while True:
 
            # on donne le premier coup à la personne qui attaque (l'objet en
            # cours). On vérifie qu'il a une arme. Si c'est le cas,
            # on appelle la méthode de l'arme "attaque()", et on lui passe
            # en paramètre l'ennemi.
            if self.arme:
                self.arme.attaque(ennemi)
 
            # condition de sortie de la boucle sur la vie du héros qui a pris
            # le coup
            if ennemi.vie <= 0:
                break
 
            # ensuite on fait pareil à l'envers pour donner une chance à l'autre
            # de répliquer : on vérifie que l'ennemi a une arme, et si c'est
            # le cas, on applique la méthode "attaque" de l'arme à l'objet
            # en cours
            if ennemi.arme:
                ennemi.arme.attaque(self)
 
            # condition de sortie de la boucle sur la vie du héros qui a pris
            # le coup
            if self.vie <= 0:
                break
 
        # une fois sorti de la boucle, on vérifie le niveau de vie pour
        # désigner le vainqueur
        if self.vie > 0:
            print "Victoire de {}".format(self.nom)
        else:
            print "{} est mort comme une pov' merde".format(self.nom)

Donc combattre utilise un objet arme, et appelle sa méthode attaque() sur un héros (j’ai viré les prints pour rendre le truc plus clair) :

    # self est l'objet en cours, donc l'arme.
    # cible est un héros, puisqu'on l'a passé en paramètre.
    def attaque(self, cible):
 
        # si la cible (l'objet héros) a un attribut protection,
        # les dégâts retirés sont diminués (ce calcul est fait par la protection)
        if cible.protection:
            cible.vie -= cible.protection.defend(self.degat)
 
        # sinon, on retire les dégâts à la vie de la cible (le héros)
        # directement
        else:
            cible.vie -= self.degat

Diantre ! La méthode attaque utilise elle-même la méthode defend() de la protection :

    # self est l'objet en cours, donc la protection.
    # degat est un simple int.
    def defend(self, degat):
        # on retourne les degâts infligés, moins la protection
        return degat - self.armure

Pour comprendre tous ces codes, il faut bien piger deux trucs :

  • Il y a 6 objets. Deux héros, deux armes, et deux protections. Les héros ont les armes / protections comme attributs.
  • On se sert des méthodes des armes pour attaquer. On passe les héros en paramètres à ces méthodes. Les armes se servent des protections des héros pour calculer les dégats.

Ce dernier point est le plus important. Si vous comprenez ça, vous avez maîtrisé le plus important de la POO. Relisez le plusieurs fois :

Les héros ont une référence aux armes. Et ensuite, on passe une référence des héros aux armes. Les armes retirent de la vie à ces héros, non sans calculer les dégâts en fonction de la protection qu’ils portent.

Les objets ont tous des références les uns vers les autres. Ils se manipulent tous les uns les autres.

Cela fait bizarre car dans la vie une épée ne manipule pas un héros (bon, je connais peu d’elfes noirs IRL aussi). On comprend facilement qu’un héros ait un attribut ‘épée’, mais il est difficile de comprendre qu’une épée ait une méthode, et que le paramètre de cette méthode soit un héros.

C’est un concept purement informatique : la logique des dégâts est codée dans l’arme, pas dans le héros. L’avantage de cette architecture, c’est que si vous changez l’arme, vous changez toute la logique des dégâts. Par exemple, vous rajoutez une arme empoisonnée :

class ArmeMegaEmpoisonnee(Arme):
 
    def __init__(self, nom, degat, poison=100000):
        super(ArmeMegaEmpoisonnee, self).__init__(nom, degat)
        self.poison = poison
 
 
    def attaque(self, cible):
 
        # on prend les degâts une premiere fois
        super(ArmeMegaEmpoisonnee, self).attaque(cible)
 
        # puis on prend les dégâts du poison
        cible.vie -= self.poison

Cette arme fait plus de dégâts. Son mécanisme pour faire des dégâts est différent. Il suffit d’équiper un héros avec l’arme (en changeant l’attribut) pour que ce nouveau calcul de dégâts soit pris en compte.

>>> noob_qui_repop.vie = 200 # rePOP !
>>> noob_qui_repop.arme = ArmeMegaEmpoisonnee('Cheat Code', 1)
>>> noob_qui_repop.combattre(gosu) # Vengeance !
Bob attaque Drizzt Do'Urden
2000 - 0 = 2000
Victoire de Bob

Ce qu’il faut retenir : on peut mettre des objets en tant qu’attributs d’objets. Il n’y a pas de limite dans les nombres d’objets à mettre, leur mélange, les niveaux d’imbrications, etc. On peut mettre des objets, dans des objets, dans des objets… C’est la composition.

Et les objets peuvent utiliser les méthodes des autres objets. Et on peut passer des objets comme paramètres à des méthodes. C’est la délégation.

C’est la partouze des objets, quoi.

On peut mettre des objets dans des sets, des dicos, des listes… Par juste dans des attributs. Il y en a des choses à faire !

Choisir entre l’héritage et la composition

Les deux techniques permettent de réutiliser du code, mais pas de la même façon. Aucune règle générale ne tient la route dans tous les cas, mais un bon point de départ est de se dire que :

  • Si vous avez deux objets de même nature et que l’un est une spécialisation de l’autre (Garçon est une spécialisation de Personne, Voiture est une spécialisation de véhicule, Clio est une spécialisation de voiture, Reptincel est une spécialisation de pokemon, foxmask est une spécialisation du correcteur orthographique de Word, etc), alors utilisez l’héritage.
  • Si vous avez deux objets qui échangent des données, qui sont associés ou qui dans la vie réelle sont des ‘part de’ (un article est une partie d’un blog, Raymond Barre est membre d’un parti, Raymond fait partie d’un bar, le bar et la raie font parti des poissons ah non ça c’est une spécialisation, etc), utilisez la composition.

Il y a aussi, quelque part, dans le lointain pays des enculeurs de mouche, une différence entre l’agrégation (qu’on a pas vu) et la composition. Vous vivrez très bien en considérant que c’est la même chose.

Le design pattern “stratégie”

Vous entendrez parfois parler du motif de conception “stratégie”. C’est en fait une mise en application abstraite de la composition.

Normalement la composition s’utilise avec des “part de” concrètes. Vous avez une voiture : elle est composée d’objets pneus, d’un objet moteur, etc.

Le design pattern stratégie est l’extraction d’une part du comportement d’un objet pour le mettre dans un autre objet, mais la nature de l’objet importe peu. Ceci est fait purement pour découpler le comportement de l’objet.

On a vu plus haut que changer l’arme permet de changer le calcul des dégâts. C’est ce type de résultat qu’on vise avec le design pattern strategy.

import os
 
class ParseurXml(object):
    ...
 
class ParseurJson(object):
    ...
 
 
class ParseurDeFichier(object):
 
    _strategy = { # les stratégie par défaut
        'json': ParseurXml,
        'xml': ParseurJson
    }
 
    def __init__(self, fichier, strategy=None):
 
        self.fichier = fichier
        # on récupère l'extension du fichier
        path, ext = os.path.splitext(fichier)
 
        # Strategy est une classe de parseur
        # on la récupère depuis les paramètres ou selon
        # l'extension
        Strategy = strategy or self._strategy[ext.lstrip('.')]
        # on instancie notre classe de strategie
        self.strategy = Strategy(fichier)
 
    def parse(self):
        # on délègue le boulot à la stratégie
        self.strategy.parse()

La ligne la plus importante est :

Strategy = strategy or self._strategy[ext]

Ici on dit récupérer la stratégie de parsing en paramètre, ou sinon, la bonne en fonction de l’extension de fichier. On charge donc une classe dynamiquement, on va créer un objet à partir de cette classe. Et c’est cet objet à qui on va déléguer le comportement du parseur :

    def parse(self):
        self.strategy.parse()

On utilise l’objet dynamiquement pour gérer tout le parsing. On peut ainsi choisir un parseur à la volée.

La pattern strategy mélange donc composition (l’objet strategy est une part de l’objet général), délégation (l’objet général utilise le comportement de l’objet strategy) et d’injection de dépendance (on peut changer l’algo à la volée, il suffit de changer de stratégie).

Bon, ça c’était le mode hard. C’est pas grave si vous finissez pas le niveau toute de suite. Mettez pause. Allez pisser un coup et revenez- plus tard, les continues sont infinis sur le blog.

C’est bon, vous êtes chaud ? Prochaine stations, le monde merveilleux des méthodes magiques.

]]>
http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-5/feed/ 58