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

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

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

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

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

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

    return _found

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

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

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

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

Bref, je vous poste la nouvelle app de Django, une app à la fois depuis le Mac Do, parce que c’est le seul truc à avoir un Wifi dans le coin paumé où je me trouve.

Machez bien, c’est assez dense.

P.S: ouinnnn, ils font plus le wrap chèvre.

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

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

J’ai choisi cette lib car :

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

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

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

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

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


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

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

# et bien d'autres choses

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

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

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

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

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

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

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

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


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

Original author:
 Jason Orendorff 

Current maintainer:
 Jason R. Coombs 

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

Example::

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

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


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

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

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

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

try:
    import pwd
except ImportError:
    pass



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

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


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


class TreeWalkWarning(Warning):
    pass


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

# Il est utilisé plus bas sur :

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

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

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

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


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

# Elle est utilisée plus loin dans:

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

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

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

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

# Par exemple dans:

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

    #

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


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

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

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


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

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

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

    # --- Special Python methods.

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


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


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

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

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

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

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

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

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

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

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

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


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

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

    #
    # --- Operations on path strings.

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

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

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

    # fait en fait:

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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


    #

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

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


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

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

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

    #

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

    #

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

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

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


    #

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

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

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

    #

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

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

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

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

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

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

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

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

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

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

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

        The elements of the list are path objects.

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

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

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

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

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

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

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

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

    #

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

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

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

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

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

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

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


    #

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

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

    # Cela permet de faire:

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

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

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

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

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

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

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

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

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

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

    #

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    #

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

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

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

    # Notez aussi le nettoyage opéré:

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

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

    #


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

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

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

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

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

        Optional arguments:

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

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

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

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

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

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

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

        Parameters:

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

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

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

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

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


        --- Newline handling.

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

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

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

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


        --- Unicode

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

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

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

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

        self.write_bytes(bytes, append)

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

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

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

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

        By default this overwrites any existing file at this path.

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

        lines - A list of strings.

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

    #
    # --- Modifying operations on files and directories

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

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

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

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

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

    #
    # --- Create/delete operations on directories

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

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

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

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

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

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

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

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

    # --- Modifying operations on files

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

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

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

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

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

    # --- Links

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

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

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

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

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

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

    #
    # --- High-level functions from shutil

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

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

    #
    # --- Special stuff from os

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

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


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

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

    Example:

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

        # here the directory is deleted automatically
    """

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

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

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

    def __enter__(self):
        return self

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

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

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

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

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

Prérequis :

• Avoir lu la partie 4.
• Etre bien au point sur la notion de références.

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.

Prérequis :

• Avoir lu (et compris) la partie 3

Aujourd’hui nous allons voir ce qui fait toute la puissance de la programmation orientée objet : l’héritage.

Héritage simple

L’héritage est un moyen de factoriser du code, c’est à dire que si on a le même code à deux endroits, l’héritage permet de centraliser ce code à un seul endroit. Ce n’est pas le seul moyen de faire ça. On peut très bien factoriser du code uniquement avec des fonctions. Néanmoins l’héritage a des caractéristiques qui rendent la factorisation très efficace.

Supposons que vous fassiez un jeu vidéo pour apprendre les prières chrétiennes, et que vous ayez une classe par prière :

class AveMaria:


    texte = ("Je vous salue, Marie pleine de grâce ;",
            "Le Seigneur est avec vous.",
            "Vous êtes bénie entre toutes les femmes",
            "Et Jésus, le fruit de vos entrailles, est béni.",
            "Sainte Marie, Mère de Dieu,",
            "Priez pour nous, pauvres pécheurs,",
            "Maintenant, et à l'heure de notre mort.",
            "Amen.")


    def prier(self, nombre_de_fois=1):

        for x in xrange(nombre_de_fois):
            for ligne in self.texte:
                print ligne



class PaterNoster:


    texte = ("Notre Père qui es aux cieux",
            "que ton nom soit sanctifié",
            "que ton règne vienne,",
            "que ta volonté soit faite",
            "sur la terre comme au ciel.",
            "Donne-nous aujourd’hui",
            "notre pain de ce jour,",
            "pardonne-nous nos offenses",
            "comme nous pardonnons aussi",
            "à ceux qui nous ont offensés",
            "et ne nous soumets pas à la tentation",
            "mais délivre-nous du mal.",
            "Amen")


    def prier(self, nombre_de_fois=1):

        for x in xrange(nombre_de_fois):
            for ligne in self.texte:
                print ligne


>>> piere = AveMaria()
>>> piere.prier()
Je vous salue, Marie pleine de grâce ;
Le Seigneur est avec vous.
Vous êtes bénie entre toutes les femmes
Et Jésus, le fruit de vos entrailles, est béni.
Sainte Marie, Mère de Dieu,
Priez pour nous, pauvres pécheurs,
Maintenant, et à l'heure de notre mort.
Amen.

Ici la méthode prier() est dupliquée. Or, c’est exactement la même. Il n’y a pas de raison de l’écrire deux fois. Nous allons utiliser l’héritage pour centraliser ce code en créant une classe Priere qui contiendra le code commun à toutes les prières :

class Priere:

    def prier(self, nombre_de_fois=1):

        for x in xrange(nombre_de_fois):
            for ligne in self.texte:
                print ligne

Ensuite, nous allons demander à toutes les classes prières d’hériter de cette classe commune :

class AveMaria(Priere): # <---- cette syntaxe veut dire 'hérite de Priere'

    texte = ("Je vous salue, Marie pleine de grâce ;",
            "Le Seigneur est avec vous.",
            "Vous êtes bénie entre toutes les femmes",
            "Et Jésus, le fruit de vos entrailles, est béni.",
            "Sainte Marie, Mère de Dieu,",
            "Priez pour nous, pauvres pécheurs,",
            "Maintenant, et à l'heure de notre mort.",
            "Amen.")


class PaterNoster(Priere):

    texte = ("Notre Père qui es aux cieux",
            "que ton nom soit sanctifié",
            "que ton règne vienne,",
            "que ta volonté soit faite",
            "sur la terre comme au ciel.",
            "Donne-nous aujourd’hui",
            "notre pain de ce jour,",
            "pardonne-nous nos offenses",
            "comme nous pardonnons aussi",
            "à ceux qui nous ont offensés",
            "et ne nous soumets pas à la tentation",
            "mais délivre-nous du mal.",
            "Amen")

Ici, les classes AveMaria et PaterNoster héritent de la classe Priere. On dit qu'elles sont les enfants (ou filles) de Priere. Ou que Priere est la classe parente de AveMaria et PaterNoster

Notez qu'on a retiré la méthode prier() de PaterNoster et AveMaria. Malgré cela, ça marche :

>>> PaterNoster().prier()
Notre Père qui es aux cieux
que ton nom soit sanctifié
que ton règne vienne,
que ta volonté soit faite
sur la terre comme au ciel.
Donne-nous aujourd'hui
notre pain de ce jour,
pardonne-nous nos offenses
comme nous pardonnons aussi
à ceux qui nous ont offensés
et ne nous soumets pas à la tentation
mais délivre-nous du mal.
Amen

Cela marche car quand on hérite d'une classe, le code de cette classe est copié de la classe parente vers la classe enfant. Ainsi, prier() est automatiquement copiée de Priere vers AveMaria et PaterNostre.

Cela marche pour toutes les méthodes, même celles appelées automatiquement. C'est particulièrement utile avec la méthode __init__:

class Priere:

    def __init__(self, expiation=False):
        self.expiation = expiation

    def prier(self, nombre_de_fois=1):

        for x in xrange(nombre_de_fois):
            for ligne in self.texte:
                if self.expiation:
                    print ligne.upper()
                else:
                    print ligne

On rajoute ici un attribut, et il se retrouve dans la classe enfant (si vous êtes dans un shell, n'oubliez pas de réécrire aussi la classe AveMaria à chaque fois, même si elle ne change pas):

>>> priere = AveMaria(expiation=True)
>>> priere.expiation
True
>>> priere.prier()
JE VOUS SALUE, MARIE PLEINE DE GRâCE ;
LE SEIGNEUR EST AVEC VOUS.
VOUS êTES BéNIE ENTRE TOUTES LES FEMMES
ET JéSUS, LE FRUIT DE VOS ENTRAILLES, EST BéNI.
SAINTE MARIE, MèRE DE DIEU,
PRIEZ POUR NOUS, PAUVRES PéCHEURS,
MAINTENANT, ET à L'HEURE DE NOTRE MORT.
AMEN.

L'héritage, c'est juste cela. Pas la peine de chercher un truc compliqué : le code du parent se retrouve dans celui de l'enfant. Cela marche pour les méthodes et les attributs.

Petit apparté sur object

Dans la partie précédente et dans de nombreux codes, vous avez dû voir des classes comme cela :

class MaClass(object): # wtf is this object stuff ?

    # code 

Il s'agit bel et bien d'héritage, object étant un type buil-in en Python au même titre que les string ou les int :

>>> object

La raison de cet héritage bizarre est qu'à partir de Python 2.2, une nouvelle architecture des classes a été introduite qui corrige les problèmes de l'ancienne. Mais pour garder le code compatible, ces nouvelles classes n'ont pas été activées par défaut.

Ainsi, même si vous êtes en Python 2.7, quand vous faites :

class MaClass:

    # code

Vous utilisez l'ancien type de classe (old-style class). Pour dire à Python que vous voulez utiliser le nouveau type de classe (new-style class), il faut hériter d'object :

class MaClass(object):

    # code 

Il n'y a AUCUN intérêt à utiliser les old-style classes. Je l'ai fais en ce début de cours pour éviter d'introduire la notion d'héritage trop tôt.

A partir de maintenant, quand vous créez une nouvelle classe qui n'a pas de parent, faites la TOUJOURS hériter de object.

Des tas de fonctions (par exemple les properties) fonctionnent beaucoup mieux avec les new-style classes. (D'ailleurs à partir de Python 3, elles sont activées par défaut)

Ainsi, notre classe Priere doit ressembler à ça maintenant :

class Priere(object):

    def __init__(self, expiation=False):
        self.expiation = expiation

    def prier(self, nombre_de_fois=1):

        for x in xrange(nombre_de_fois):
            for ligne in self.texte:
                if self.expiation:
                    print ligne.upper()
                else:
                    print ligne

Overriding

Parfois on veut tout le code du parent dans l'enfant. Parfois juste une partie. L'héritage vous permet de réécrire certaines méthodes du parent dans l'enfant, c'est ce qu'on appelle l'overriding.

Quand vous faites :

class Parent(object):

    def truc(self):
        print 'foo'


class Enfant(Parent):

    pass

En fait vous faites en quelque sorte :

class Enfant(object):

    def truc(self):
        
        print 'foo'

Si vous faites :

class Enfant(object):

    def truc(self):
        
        print 'foo'

    def truc(self):

        print 'bar'

Vous allez écraser la première méthode avec la deuxième, car elles portent toutes les deux le même nom :

>>> Enfant().truc()
bar

"Ecraser" en anglais, se dit "to override". Félicitation, vous venez d'apprendre l'overriding ! Ce qu'on vient de voir plus haut s'écrit comme ça dans le cadre de l'héritage :

class Parent(object):

    def truc(self):
        print 'foo'

class Enfant1(Parent): 
    pass # pas d'overriding

class Enfant2(Parent):

    def truc(self):
        print 'bar' # overriding !


>>> Enfant1().truc()
foo
>>> Enfant2().truc()
bar

Enfant1 a tout le code du parent qui est copié. Enfant2 aussi, mais il réécrit la méthode, donc sa version de la méthode écrase celle du parent.

Voyons ce que ça donne sur un cas plus concret dans la vie de tous les jours comme les prières chrétiennes (promis je fais les sourates du Coran si je fais un tuto Haskell) :

class Priere(object):

    def __init__(self, expiation=False):
        self.expiation = expiation

    def prier(self, nombre_de_fois=1):

        for x in xrange(nombre_de_fois):
            for ligne in self.texte:
                if self.expiation:
                    print ligne.upper()
                else:
                    print ligne


class PaterNoster(Priere):

    texte = ("Notre Père qui es aux cieux",
            "que ton nom soit sanctifié",
            "que ton règne vienne,",
            "que ta volonté soit faite",
            "sur la terre comme au ciel.",
            "Donne-nous aujourd’hui",
            "notre pain de ce jour,",
            "pardonne-nous nos offenses",
            "comme nous pardonnons aussi",
            "à ceux qui nous ont offensés",
            "et ne nous soumets pas à la tentation",
            "mais délivre-nous du mal.",
            "Amen")


# sur avemaria, on veut mettre en avant la version en araméen
# car l'araméen c'est trop cool (ça ressemble au langage des furlings
# dans stargate)


class AveMaria(Priere): 

    vf = ("Je vous salue, Marie pleine de grâce ;",
            "Le Seigneur est avec vous.",
            "Vous êtes bénie entre toutes les femmes",
            "Et Jésus, le fruit de vos entrailles, est béni.",
            "Sainte Marie, Mère de Dieu,",
            "Priez pour nous, pauvres pécheurs,",
            "Maintenant, et à l'heure de notre mort.",
            "Amen.")

    vo = ("ܡܠܝܬ ܛܝܒܘܬܐ",
          "ܡܪܢ ܥܡܟܝ",
          "ܡܒܪܟܬܐ ܐܢܬܝ ܒܢܫ̈ܐ",
          "ܘܡܒܪܟ ܗܘ ܦܐܪܐ ܕܒܟܪܣܟܝ ܡܪܢ ܝܫܘܥ",
          "ܐܘ ܩܕܝܫܬܐ ܡܪܝܡ ܝܠܕܬ ܐܠܗܐ",
          "ܨܠܝ ܚܠܦܝܢ ܚܛܝ̈ܐ",
          "ܗܫܐ ܘܒܫܥܬ ܘܡܘܬܢ",
          "ܐܡܝܢ܀")


    def prier(self, nombre_de_fois=1, version='vo'):

        for x in xrange(nombre_de_fois):
            for ligne in getattr(self, version, 'vo'):
                if self.expiation:
                    print ligne.upper()
                else:
                    print ligne

>>> AveMaria().prier()
ܡܠܝܬ ܛܝܒܘܬܐ
ܡܪܢ ܥܡܟܝ
ܡܒܪܟܬܐ ܐܢܬܝ ܒܢܫ̈ܐ
ܘܡܒܪܟ ܗܘ ܦܐܪܐ ܕܒܟܪܣܟܝ ܡܪܢ ܝܫܘܥ
ܐܘ ܩܕܝܫܬܐ ܡܪܝܡ ܝܠܕܬ ܐܠܗܐ
ܨܠܝ ܚܠܦܝܢ ܚܛܝ̈ܐ
ܗܫܐ ܘܒܫܥܬ ܘܡܘܬܢ
ܐܡܝܢ܀
>>> AveMaria().prier(2, 'vf')
Je vous salue, Marie pleine de grâce ;
Le Seigneur est avec vous.
Vous êtes bénie entre toutes les femmes
Et Jésus, le fruit de vos entrailles, est béni.
Sainte Marie, Mère de Dieu,
Priez pour nous, pauvres pécheurs,
Maintenant, et à l'heure de notre mort.
Amen.
Je vous salue, Marie pleine de grâce ;
Le Seigneur est avec vous.
Vous êtes bénie entre toutes les femmes
Et Jésus, le fruit de vos entrailles, est béni.
Sainte Marie, Mère de Dieu,
Priez pour nous, pauvres pécheurs,
Maintenant, et à l'heure de notre mort.
Amen.

Ici la classe AveMaria hérite de la classe Priere. Deux méthodes sont copiées de Priere vers AveMaria : __init__ et prier().

__init__ ne change pas. Donc AveMaria a toujours le __init__ de Priere. Par contre, on a overridé prier() dans AveMaria, qui est maintenant un code personnalisé.

Ceci nous permet donc de bénéficier d'une partie du code en commun (__init__), et de choisir un comportement différent pour d'autres bout du code (prier()).

La classe PaterNoster, elle, n'est pas affectée. Elle n'override rien, et sa méthode prier() est la même que celle de Priere.

Peut-être voulez-vous une exemple plus terre à terre (et moins dans les cieux) :

Prenez la bibliothèque path.py, par exemple. Normalement quand on additionne deux strings, ça les concatène. Mais quand on les divise, le comportement par défaut est de lever une erreur.

>>> '/home/sam' + '/blog'
'/home/sam/blog'
>>> '/home/sam' / '/blog'
Traceback (most recent call last):
  File "", line 1, in 
    '/home/sam' / '/blog'
TypeError: unsupported operand type(s) for /: 'str' and 'str'

Path.py override ce comportement :

import os

class path(str): # hé oui, on peut hériter des types de base

    def __div__(self, other): # override le comportement face à l'opérateur '/'

        return path(os.path.join(self, other))

... p = path('/home/sam')
... print p / 'blog'
/home/sam/blog

Ca nous donne une très jolie interface pour la manipulation des chemins d'accès.

Polymorphisme et autres diableries

Comme d'hab en prog, on adore les mots qui font super hype de la vibes du flex.

Le polymorphisme fait partie de ces termes compliqués qui cachent une notion simple : avoir une API commune qui fait des choses différentes.

Voyez-vous, nos deux classes AveMaria et PaterNoster, sont toutes les deux filles de la même classe parente. Elles se ressemblent donc beaucoup : elles ont des attributs et des méthodes en commun :

>>> p1 = AveMaria()
>>> p2 = PaterNoster()
>>> p1.expiation
False
>>> p2.expiation
False
>>> p1.prier
>
>>> p2.prier
>
>>> p1.__init__
>
>>> p2.__init__
>

Ce sont pourtant des classes différentes (et prier() ne fait pas du tout le même chose), mais elles partagent ce qu'on appelle une API (une interface), c'est à dire une manière de les utiliser.

Cette capacité à être utilisé pareil, mais produire un résultat diffférent est ce qu'on appelle le polymorphisme (et c'est la base du duck typing). Concrètement ça veut dire que vous pouvez utiliser les deux classes dans le même contexte, sans vous soucier de si c'est l'une ou l'autre :

>>> prieres = [AveMaria(), AveMaria(), PaterNoster(), AveMaria(), PaterNoster()]
>>> prieres
[<__main__.AveMaria object at 0x2061d50>, <__main__.AveMaria object at 0x2061d90>, <__main__.PaterNoster object at 0x2061f50>, <__main__.AveMaria object at 0x2061f90>, <__main__.PaterNoster object at 0x2061fd0>]
>>> for priere in prieres: 
...     priere.prier() # prier une prière, ça se fait pareil

ܡܠܝܬ ܛܝܒܘܬܐ
ܡܪܢ ܥܡܟܝ
ܡܒܪܟܬܐ ܐܢܬܝ ܒܢܫ̈ܐ
ܘܡܒܪܟ ܗܘ ܦܐܪܐ ܕܒܟܪܣܟܝ ܡܪܢ ܝܫܘܥ
ܐܘ ܩܕܝܫܬܐ ܡܪܝܡ ܝܠܕܬ ܐܠܗܐ
ܨܠܝ ܚܠܦܝܢ ܚܛܝ̈ܐ
ܗܫܐ ܘܒܫܥܬ ܘܡܘܬܢ
ܐܡܝܢ܀
ܡܠܝܬ ܛܝܒܘܬܐ
ܡܪܢ ܥܡܟܝ
ܡܒܪܟܬܐ ܐܢܬܝ ܒܢܫ̈ܐ
ܘܡܒܪܟ ܗܘ ܦܐܪܐ ܕܒܟܪܣܟܝ ܡܪܢ ܝܫܘܥ
ܐܘ ܩܕܝܫܬܐ ܡܪܝܡ ܝܠܕܬ ܐܠܗܐ
ܨܠܝ ܚܠܦܝܢ ܚܛܝ̈ܐ
ܗܫܐ ܘܒܫܥܬ ܘܡܘܬܢ
ܐܡܝܢ܀
Notre Père qui es aux cieux
que ton nom soit sanctifié
que ton règne vienne,
que ta volonté soit faite
sur la terre comme au ciel.
Donne-nous aujourd’hui
notre pain de ce jour,
pardonne-nous nos offenses
comme nous pardonnons aussi
à ceux qui nous ont offensés
et ne nous soumets pas à la tentation
mais délivre-nous du mal.
Amen
ܡܠܝܬ ܛܝܒܘܬܐ
ܡܪܢ ܥܡܟܝ
ܡܒܪܟܬܐ ܐܢܬܝ ܒܢܫ̈ܐ
ܘܡܒܪܟ ܗܘ ܦܐܪܐ ܕܒܟܪܣܟܝ ܡܪܢ ܝܫܘܥ
ܐܘ ܩܕܝܫܬܐ ܡܪܝܡ ܝܠܕܬ ܐܠܗܐ
ܨܠܝ ܚܠܦܝܢ ܚܛܝ̈ܐ
ܗܫܐ ܘܒܫܥܬ ܘܡܘܬܢ
ܐܡܝܢ܀
Notre Père qui es aux cieux
que ton nom soit sanctifié
que ton règne vienne,
que ta volonté soit faite
sur la terre comme au ciel.
Donne-nous aujourd’hui
notre pain de ce jour,
pardonne-nous nos offenses
comme nous pardonnons aussi
à ceux qui nous ont offensés
et ne nous soumets pas à la tentation
mais délivre-nous du mal.
Amen

Le polymorphisme, c'est donc l'utilisation de l'héritage pour faire des choses différentes, mais en proposant la même interface (ensemble de méthodes et d'attributs) pour le faire. Le polymorphisme s'étend aussi à la réaction aux opérateurs (+, -, /, or, and, etc), d'autant qu'en Python, c'est implémenté avec les méthodes nommées avec __.

Un dernier point pour les gens qui se demandent ce que veut dire overloader. L'overload est lié à l'override et au polymorphisme, mais ce n'est pas la même chose : elle consiste à overrider plusieurs fois une même méthode avec une signature différente. Il n'y a pas d'overload en Python, la notion ne nous concerne donc pas. Si vous voulez en apprendre plus, chopez un tuto Java ou C++.

Qui est qui

Avec l'héritage vient la notion de type. Quand vous créez une classe, vous créez un nouveau type. Quand vous sous-classez, vous créez un sous-type.

C'est intéressant, car une classe fille, est de son propre type ET du type de son parent (mais l'inverse n'est pas vrai).

Avec Python, on vérifie cela avec isinstance() :

>>> isinstance(Priere(), Priere) # instance de sa propre classe
True
>>> isinstance(Priere(), str) # pas l'instance d'une classe quelconque
False
>>> isinstance(Priere(), AveMaria) # pas l'instance d'un enfant
False
>>> isinstance(AveMaria(), AveMaria) # instance de sa propre classe
True
>>> isinstance(AveMaria(), Priere) # instance de sa classe parente
True

C'est utile, car certains comportements sont basés sur le type. Le plus important étant le mécanisme des exceptions. Un try / except arrêtera l'exception demandée, ou du même type.

class MonExceptionPerso(Exception):
    pass


class FillesDeMonExceptionPerso(MonExceptionPerso):
    pass


try:
    raise MonExceptionPerso('Alerte ! Alerte !')
except MonExceptionPerso:
    print 'Exception arrêtée'


try:
    raise FillesDeMonExceptionPerso('Alerte ! Alerte !')
except FillesDeMonExceptionPerso:
    print 'Exception arrêtée'


try:
    raise FillesDeMonExceptionPerso('Alerte ! Alerte !')
except MonExceptionPerso:
    print 'Exception arrêtée'    



try:
    raise MonExceptionPerso('Alerte ! Alerte !')
except FillesDeMonExceptionPerso:
    print 'Exception arrêtée'    


Exception arrêtée
Exception arrêtée
Exception arrêtée
Traceback (most recent call last):
  File "", line 21, in 
    raise MonExceptionPerso('Alerte ! Alerte !')
MonExceptionPerso: Alerte ! Alerte !

MonExceptionPerso est de type MonExceptionPerso, donc l'exception est arrêtée. FillesDeMonExceptionPerso est de type FillesDeMonExceptionPerso, donc l'exception est arrêtée. FillesDeMonExceptionPerso, qui hérite de MonExceptionPerso, et donc de type MonExceptionPerso est arrêtée.

En revanche, MonExceptionPerso n'est PAS de type FillesDeMonExceptionPerso. Donc elle n'est pas arrêtée.

Je le signale car il est très courant de faire des enfants de ValueError, IOError, IndexError, KeyError, etc. et de le lever dans son propre programme. Cela permet à l'utilisateur de son code de pouvoir attraper soit toutes les erreurs de son code en faisant un except sur l'enfant, soit attraper toutes les erreurs de type ValueError, IOError, IndexError, KeyError en faisant le except sur le parent. On laisse ainsi une marge de manoeuvre dans la gestion des erreurs.

Appeler la méthode de la classe parent

Bon, vous avez overridé une méthode du parent. Mais c'est une groooooooooooooossse méthode. Vous allez pas la réécrire en entier, si ?

class Escorte(object):

    def calculer_prix(self, heures, tarif):

        return heures * tarif


class EscorteDeLuxe(Escorte):

    def calculer_prix(self, heures, tarif, supplement):

        tarif =  heures * tarif

        return tarif + (tarif * supplement / 100)

Sur cet exemple éminement intellectuel, calculer_prix() est simple, donc tout réécrire dans EscorteDeLuxe n'est pas grave. Mais si c'était une Geisha, hein ? Avec un manuel en Japonais ?

Pour éviter ces problèmes de complexité liés à la globalisation, le perméabilisation des frontières et les sites de streaming, on peut appeler la méthode du parent, dans l'enfant, en utilisant super():

class EscorteDeLuxe(Escorte):

    def calculer_prix(self, heures, tarif, supplement):

        # ceci est une manière compliquée de faire Escorte.calculer_prix
        # et de récupérer le résultat
        tarif =  super(EscorteDeLuxe, self).calculer_prix(heures, tarif)

        return tarif + (tarif * supplement / 100)

C'est exactement la même chose que plus haut. Sauf qu'au lieu de copier / coller le code du parent, on l'appelle directement.

Je résume :

• on hérite du parent, et de son code
• on override son code, car on veut un comportement différent
• mais on veut quand même une partie du comportement du parent
• donc dans la méthode de l'enfant, on appelle la méthode du parent

Je réformule : quand vous overridez la méthode du parent dans l'enfant, celle du parent ne disparait pas. Elle est remplacée uniquement dans l'enfant. Et vous pouvez toujours vous servir de la version du parent en utilisant super(ClassEncours, self).nom_de_method(arguments) si vous en avez besoin.

Bon, c'était un gros morceau, et je suis pas sûr de pas être allé trop fort. Donc laissez en comment les remarques sur ce qui pourrait être mieux expliqué. La prochaine fois, on verra des usages poussés comme la composition, la délégation et tous ces trucs d'un vrai code de production.

Par exemple:

class Truc(threading.Condition):
    pass

class Machine(tempfile.NamedTemporaryFile):
    pass

Lèveront l’exception :

TypeError: Error when calling the metaclass bases 
    function() argument 1 must be code, not str

Car:

>>> import threading, tempfile
>>> type(threading.Condition)

>>> type(tempfile.NamedTemporaryFile)

Malgré leurs noms en majuscule.

Le message d’erreur est lui-même complètement obscure. Bref, le genre de truc qui est 100% lié à des erreurs d’autres personnes que vous aller payer par une après-midi de debug si on ne vous donne pas la solution.

Mais bon, la queue de celui qui n’a jamais pourri l’après-midi d’un autre codeur avec son travail merdique jette le premier parpaing.