Sam & Max: Python, Django, Git et du cul » poo http://sametmax.com Deux développeurs en vadrouille qui se sortent les doigts du code Wed, 05 Feb 2014 14:20:37 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Ecrire un code pour les autres en Python http://sametmax.com/ecrire-un-code-pour-les-autres-en-python/ http://sametmax.com/ecrire-un-code-pour-les-autres-en-python/#comments Sat, 17 Aug 2013 13:15:07 +0000 Sam http://sametmax.com/?p=7122 Cet article s’adresse à des développeurs qui commencent à être bien dans leurs chaussettes en Python et qui se sentent de relever le défi d’écrire du code pour d’autres personnes.

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

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

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

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

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

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

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

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

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

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

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

Et roulez jeunesse !

# -*- coding: utf-8 -*-
 
 
 
import sys
 
from io import IOBase
 
 
# On hérite d'IOBase pour permettre le détournement de stdout. Voir plus bas.
class ProgressBar(IOBase):
 
 
    # On met les paramètres par ordre de fréquence d'utilisation. Il est
    # plus probable que les programmeurs changent le total que la sortie
    # du programme.
    # Mettre des valeurs par défaut saines permet à l'utilisateur de faire
    # des essais sans trop regarder la doc. Par ailleurs, des valeurs par
    # défaut servent de documentation en soit, et apparaitront si help()
    # est appelé.
    def __init__(self, total=100,  percent_per_sign=1,
                 progress_sign='=', callbacks=(),
                 template='Starting [{bar}] {progress}%',
                 output=sys.stdout, intercept_stdout=True):
 
        # Par défaut le total est 100, afin que l'utilisateur passe un
        # pourcentage, ce qui est le plus naturel. Néanmoins, si il souhaite
        # s'affranchir de calculs, on lui permet de passer une autre valeur
        # qui sera ramenée à un pourcentage automatiquement à l'affichage
        # de toute façon.
        self.total = total
 
        # Customisation de base : changer le symbole de progrès. Par défaut
        # un égal, mais certains aiment les ., les - ou autre.
        self.progress_sign = progress_sign
 
        # Idem, si la personne veut une barre plus ou moins longue.
        self.percent_per_sign = percent_per_sign
 
        # la longueur de la barre de progression
        self.bar_len = 100 / percent_per_sign * len(progress_sign)
 
        # Le formatage de la progress bar se fait à l'aide d'une chaîne
        # ordinaire qui sert de template (avec le langage de formatage de Python)
        # et peut facilement être changée pour obtenir plus de contrôle
        # sur l'aspect de la bar.
        self.template = template
 
        # On peut aussi passer un tuple de fonctions qui permettent de réagir
        # à chaque fois que le progrès change. On utilise nous-même notre
        # système de callback pour que la methode print_progress() soit
        # appelée à chaque fois, mettant à jour l'affichage de la bar.
        self.callbacks = callbacks + (self.print_progress,)
 
        # Initialisation de 3 variables à vide. 'buffer' va contenir
        # tout ce qui va être écrit avec write() pour éviter de perturber
        # l'affichage de la bar, et '_progress' va contenir le progrès, mais
        # le '_' signale que c'est une variable à usage interne. Nous allons
        # en effet l'enrober dans une propriété. Enfin cursor_shift est
        # le nombre de caractères à effacer pour redessiner la bar à chaque
        # mise à jour.
        self.buffer = ''
        self._progress = 0
        self.cursor_shift = 0
 
        # Par défaut, on s'attend à ce que l'utilisateur affiche cette
        # bar directement dans le terminal, sur la sortie standard. Mais
        # il peut vouloir déporter l'affichage ailleurs (par exemple stderr).
        # Pour cette raison, on permet de passer le stream sur lequel
        # l'utilisateur va écrire, même si par défaut on prend sys.stdout,
        # donc la sortie standard.
        # Si l'utilisateur ne souhaite rien de tout cela, il peut également
        # retirer 'self.print_progress' de la liste des callbacks puisque
        # l'attribut est public.
        self.out = output
 
        # Comme on utilise la sortie standard par défaut, la barre peut
        # facilement être cassée par un autre code écrivant aussi sur la sortie
        # standard. Puisqu'un débutant ne comprendra pas rour se suite ce qui se
        # passe, par défaut on va intercepter stdout et mettre tout ce qui est
        # écrit dessus dans un buffer. Si jamais il y a des prints fait durant
        # l'affichage, il seront cachés, et stockés. Ce comportement n'est pas
        # forcément désirable, et peut donc être désactivé par un paramètre pour
        # l'utilisateur qui sait ce qu'il fait notamment dans le cadre
        # d'utilisation des threads.
        self._intercept_stdout = intercept_stdout and self.out == sys.stdout
        if self._intercept_stdout:
            # L'interception de la sortie standard se fait en remplaçant
            # sys.stdout par soi-même. C'est pour cette raison que ProgressBar
            # hérite de IOBase. En effet, de cette manière, on possède
            # l'interface d'un objet stream et tout écriture sur 'self' semblera
            # fonctionner comme sur sys.stdout. Cela permet de faire des prints
            # ou de lancer un shell et d'utiliser la barre, bien que
            # dans un shell cela monopolisera le prompt.
            sys.stdout = self
 
 
    # Afficher la barre à la création de l'objet retire de la flexibilité à
    # l'utilisateur qui peut vouloir le créer d'un côté, le stocker, et
    # démarrer l'affichage plus tard. L'affichage est donc conditionné
    # par cette méthode.
    def show(self):
        bar = self.format()
        self.out.write(bar)
        self.cursor_shift = len(bar)
        return self
 
    # Comme le plus souvent on voudra tout de même afficher la barre juste après
    # la création, on transforme cette classe en context manager. Pour cela on
    # créer un alias de la method show() qu'on appelle __enter__, puisque tout
    # objet qui a une méthode nommée __enter__ peut être utilisé comme context
    # manager. Si vous ne vous souvenez pas de ce que c'est, il y a un article
    # sur le blog à ce sujet. Mais en résumé, ce sont les objets utilisables
    # avec "with".
    # Notez qu'on ne fait pas __enter__ = show, ce qui serait un moyen plus
    # court d'aliaser, car il empêcherait __enter__ d'appeler le bon show()
    # en cas d'héritage, si show() est écrasé.
    def __enter__(self):
        return self.show()
 
 
    # Une petit méthode de nettoyage, qui ici va simplement remettre sys.stdout
    # à sa place.
    def stop(self, *args, **kwargs):
        if self._intercept_stdout:
            sys.stdout = self.out
 
    # Même topo, on alias stop en __exit__ pour avoir la sortie du context
    # manager. On a pas appelé directement ces méthodes __enter__ et __exit__
    # car l'utilisateur peut vouloir les appeler manuellement.
    def __exit__(self, *args, **kwargs):
        return self.stop()
 
 
    # Une simple propriété qui donne accès au progres en lecture...
    @property
    def progress(self):
        return self._progress
 
 
    # ... et en écriture. La différence étant qu'à l'écriture, on vérifie
    # que la valeur est bien comprise entre 0 et le total. On appelle aussi
    # les callbacks, et donc l'affichage se mettra à jour.
    @progress.setter
    def progress(self, value):
 
        if not 0 <= value <= self.total:
            raise ValueError("'value' is %s and should be set between 0 "
                             "and 'total' (%s)" % (value, self.total))
 
        # On le fait avant car les callbacks doivent être appelés
        # avec un état propre.
        previous_progress = self._progress
        self._progress = value
 
        # Ce que l'on va passer en paramètres aux callbacks est un choix
        # important. Déjà en premier paramètre, on passe self. Ainsi le callback
        # aura accès à presque tout, et on est certain qu'il ne se trouvera
        # pas dépourvu d'informations. Ensuite on passe le progrès. Normalement
        # il peut le récupérer à travers self.progress, mais comme on sait
        # que c'est une information très utilisée, on la passe par politesse,
        # pour faciliter la vie de l'utilisateur. Enfin, une information qu'il
        # ne pourrait pas avoir autrement est le progrès précédent. Bien que
        # nous ne l'utilisons pas dans notre callback, on peut imaginer que
        # c'est le genre d'info qui peut être utile, et qui ne peut être trouvée
        # dans self.
        for callback in self.callbacks:
            callback(self, self._progress, previous_progress)
 
        # Si on arrive au bout, on appelle stop() automatiquement. Stop()
        # étant idempotente, ce n'est pas grave si elle est appelée plusieurs
        # fois.
        if value == self.total:
            self.stop()
 
    # Un cas intéressant : pourquoi on ne fait pas self.template directement au
    # lieu de créer une property à vide ? Tout simplement parce qu'un template
    # est typiquement quelque chose que quelqu'un peut vouloir créer
    # dynamiquement (par exemple pour y ajouter une notion de temps qui passe).
    # Donc, on propose de passer le template en paramètre  dans __init__ car la
    # plupart du temps, c'est juste ce qu'on voudra faire : un simple changement
    # cosmétique statique. Mais afin de permettre plus d'extensibilité, on en
    # fait une propriété, qui, comme toute méthode, peut être écrasée avec de
    # l'héritage et permettrait à l'utilisateur de vraiment personnaliser son
    # affichage de manière poussée.
    @property
    def template(self):
        return self._template
 
    @template.setter
    def template(self, value):
        self._template = value
 
    # C'est cette méthode qui est appelée si on a détourné sys.stdout quand
    # l'utilisateur va faire un print. Elle doit s'appeler write(), car c'est
    # l'interface connue des objets stream. Grosso modo, on va juste
    # tout stocker dans une variable plutôt que d'afficher quoique ce soit
    def write(self, value):
        self.buffer += value
 
    # Pour une progrès donné, retourne la barre de progrès sous forme de
    # string ASCII. Elle est mise à part car elle peut ainsi être facilement
    # utilisée dans un callback.
    def format(self, progress=0):
        progress = progress * 100 / self.total
        bar = progress / self.percent_per_sign * self.progress_sign
        bar += (self.bar_len - len(bar)) * ' '
        return self.template.format(bar=bar, progress=progress)
 
 
    # Notre callback que l'on utilise pour afficher la barre. C'est une méthode
    # statique car cela nous permet de nous mettre dans les conditions exacte
    # d'un callback d'un utilisateur, qui ne sera qu'une fonction, sans self.
    @staticmethod
    def print_progress(progress_bar, progress, previous_progress):
        # '\b' permet de reculer le curseur dans le terminal, ce qui va
        # nous permettre de réécrire par dessus l'ancienne bar, et la mettre
        # à jour. Si vous tenez à faire un display multi ligne, sachez que '\b'
        # ne permet pas de reculer sur un saut de ligne, pour ça il faut
        # utiliser '\033[1A'
        progress_bar.out.write(progress_bar.cursor_shift * '\b')
        bar = progress_bar.format(progress)
        progress_bar.out.write(bar)
        # flush est nécessaire pour vider le buffer et obtenir un affichage
        # immédiat quand on écrit en direct sur un stream.
        progress_bar.out.flush()
        # on met à jour l'avancement du curseur, qui nous permettra de reculer
        # d'autant au prochain print_progress()
        progress_bar.cursor_shift = len(bar)
 
 
 
if __name__ == "__main__":
 
    # voici une utilisation standard de la barre :
 
    import time
 
    total = 1000
    # L'utilisation du context manager permet de ne pas se soucier d'appeler
    # show() ou stop() et autre détails d'implémentation.
    # On note aussi qu'avoir des valeurs par défaut pour l'initialisation de la
    # barre la rend très facile à utiliser sans trop se prendre la tête, et
    # ce malgré un code derrière assez complexe. On aurait même pu se passer
    # de "total".
    with ProgressBar(total) as pb:
 
        for i in range(total):
            time.sleep(0.001)
            # on voir l'interêt d'utiliser une property ici, ça rend la mise
            # à jour du progrès très simple
            pb.progress = i
            if i == total / 2:
                print("\nHalf the work already !")
                half = True
            if i == total * 0.7:
                print("Almost done")
                almost = True
 
        pb.progress = total
 
    # On peut afficher tout ce qui a été printé durant la progression de la
    # barre si besoin.
    print(pb.buffer)
 
    from datetime import datetime
 
    # Et une utilisation custo où on compte les secondes depuis le départ
    # et on les affiches dans le template
 
    class MaProgressBar(ProgressBar):
 
        def show(self):
            self.start = datetime.now()
            return super(MaProgressBar, self).show()
 
        # Comme on a template en tant que méthode, on peut l'overrider et
        # obtenir un comportement
        @property
        def template(self):
            seconds = (datetime.now() - self.start).seconds
            return '{bar} (running for %s seconds)' % seconds
 
        @template.setter
        def template(self, value):
            pass
 
    # Notre système de callback va se trouver utile :
    # on met un callback de plus qui va écrire dans un fichier (mais
    # il pourrait faire n'importe quoi, envoyer un post sur un site Web,
    # un mail, formatter le disque...)
    def update_progress(progress_bar, progress, previous_progress):
        with open('/tmp/progress.log', 'w') as log:
            log.write(str(progress))
 
    # On change aussi le signe de progrès pour quelque chose de plus pro
    pb = MaProgressBar(progress_sign=':-) ', percent_per_sign=10,
                       callbacks=(update_progress,))
 
    # Au besoin, on peut passer à l'affichage en manuel.
    pb.show()
 
    for i in range(100):
        time.sleep(.1)
        pb.progress = i
 
    pb.progress = 100
 
    pb.stop()

Télécharger le code de l’article

flattr this!

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

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

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

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

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

S’il vous plait, dessine moi un objet proxy

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

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

class Enseignant(object):
 
    # la demande d'autorisation attend un objet enfant en paramètre
    def demande_autorisation_de_sortie(self, enfant):
        return enfant.peut_sortir()
 
 
class Enfant(object):
 
    def __init__(self, age):
        self.age = age
 
    # mais un enfant ne peut pas donner cette information
    def peut_sortir(self):
        raise NotImplementedError('Un enfant ne peut decider de cela')
 
 
class Parent(object):
 
    # le parent va faire proxy sur l'objet enfant
    def __init__(self, enfant):
        self.enfant = enfant
 
    # et propose la même méthode que l'objet enfant afin de pouvoir
    # être passé en paramètre à sa place à la méthode
    # demande_autorisation_de_sortie()
    def peut_sortir(self):
        return self.enfant.age > 10

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

>>> prof = Enseignant()
>>> enfant = Enfant(11)
>>> prof.demande_autorisation_de_sortie(enfant)
Traceback (most recent call last):
  File "<ipython-input-23-6d509f016e40>", line 1, in <module>
    prof.demande_autorisation_de_sortie(enfant)
  File "<ipython-input-18-e8d34178df4c>", line 4, in demande_autorisation_de_sortie
    return enfant.peut_sortir()
  File "<ipython-input-18-e8d34178df4c>", line 13, in peut_sortir
    raise NotImplementedError('Un enfant ne peut decider de cela')
NotImplementedError: Un enfant ne peut decider de cela

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

class Videur(object):
 
    def tu_peux_rentrer(self, personne):
 
        if hasattr(personne, 'age'):
            return personne.age >= 18
 
        return personne.majeur

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

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

Les connards. Ah les connards.

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

import datetime
 
class Videur(object):
 
    def tu_peux_rentrer(self, personne):
 
        if hasattr(personne, 'age'):
            return personne.age >= 18
 
        if hasattr(personne, 'date_de_naissance'):
            # TODO: prendre en compte les années bisextiles
            return (datetime.datetime.now() - personne.date_de_naissance) / 365 > 18
 
        return personne.majeur

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

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

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

class Videur(object):
 
    def tu_peux_rentrer(self, personne):
 
        if hasattr(personne, 'age'):
            return personne.age >= 18
 
        if hasattr(personne, 'date_de_naissance'):
            # TODO: prendre en compte les années bisextiles
            return (datetime.datetime.now() - personne.date_de_naissance) / 365 > 18
 
        if hasattr(personne, 'get_majeur_de_combien'):
            # retourne le nombre d'années après 18 ans ou -1. Don't ask...
            return personne.get_majeur_de_combien() > -1
 
        return personne.majeur

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

class CarteDeMembre(object):
    pass
 
 
class CarteIdentité(object):
    def __init__(self, date_de_naissance):
        self.date_de_naissance = date_de_naissance
 
 
class Client(object):
    def __init__(self, majeur=None, carte_identite=None, carte_membre=None):
        self.majeur = majeur
        self.carte_identite = carte_identite
        self.carte_membre = None
 
 
class Videur(object):
 
    def tu_peux_rentrer(self, personne):
 
        if hasattr(personne, 'age') and personne.age is not None:
            return personne.age >= 18
 
        if hasattr(personne, 'carte_membre'):
            return True
 
        if hasattr(personne, 'carte_identite') and personne.carte_identite is not None:
            now = datetime.datetime.now()
            return (now - personne.carte_identite.date_de_naissance) / 365 > 18
 
        if hasattr(personne, 'date_de_naissance'):
            # TODO: prendre en compte les années bisextiles
            return (datetime.datetime.now() - personne.date_de_naissance) / 365 > 18
 
        if hasattr(personne, 'get_majeur_de_combien'):
            # retourne le nombre d'années après 18 ans ou -1. Don't ask...
            return personne.get_majeur_de_combien() > -1
 
        return personne.majeur
 
 
class Controleur(object):
 
    def est_autorise(self, personne):
 
        if hasattr(personne, 'age') and personne.age is not None:
            return personne.age >= 18
 
        if hasattr(personne, 'carte_identite') and personne.carte_identite is not None:
            now = datetime.datetime.now()
            return (now - personne.carte_identite.date_de_naissance) / 365 > 18
 
        if hasattr(personne, 'date_de_naissance'):
            # TODO: prendre en compte les années bisextiles
            return (datetime.datetime.now() - personne.date_de_naissance) / 365 > 18
 
        if hasattr(personne, 'get_majeur_de_combien'):
            # retourne le nombre d'années après 18 ans ou -1. Don't ask...
            return personne.get_majeur_de_combien() > -1
 
        return personne.majeur

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

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

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

 
# on met le code commun dans un parent abstrait, notamment le check pour
# savoir si un adapter convient a un objet donné
class Adapteur(object):
 
    cls = None
 
    def __init__(self, objet):
        self.objet = objet
 
    def peut_adapter(self, objet):
        return self.cls == type(objet)
 
 
# un adapter, c'est juste un objet proxy qui arrondit les angles
class PersonneAdapteur(Adapteur):
 
    cls = Personne
 
    # on va réduire la complexité en faisant en sorte que tous les checks
    # soient cachés derrière une simple property
    @property
    def majeur(self):
        return self.objet >= 18
 
 
class ProspectAdapteur(Adapteur):
 
    cls = Prospect
 
    @property
    def majeur(self):
        # TODO: prendre en compte les années bisextiles
        return (datetime.datetime.now() - self.objet.date_de_naissance) / 365 > 18
 
 
class LeClientAdapteur(Adapteur):
 
    cls = LeClient
 
    @property
    def majeur(self):
        # retourne le nombre d'années après 18 ans ou -1. Don't ask...
        return self.objet.get_majeur_de_combien() > -1
 
 
class ClientAdapteur(Adapteur):
 
    cls = Client
 
    def __init__(self, objet):
        self.objet = objet
 
    @property
    def majeur(self):
 
        if self.accepte_carte_membre and self.objet.carte_membre is not None:
            return True
 
        if self.objet.majeur:
            return True
 
        if self.object.carte_identite is not None:
            now = datetime.datetime.now()
            # TODO: prendre en compte les années bisextiles
            return (now - personne.carte_identite.date_de_naissance) / 365 > 18
 
        return False

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

class VerificateurDeMajorite(object):
    def check_majorite(self, personne):
        for adapteur in self.adapteurs:
            if adapteur.peut_adapter(personne):
                return adapteur(personne).majeur
 
# du coup un vérificateur, c'est très déclaratif
class Videur(VerificateurDeMajorite):
 
    adapteurs = (
        PersonneAdapteur,
        ClientAdapteur,
        ProspectAdapteur,
        LeClientAdapteur,
    )
 
    def tu_peux_rentrer(self, personne):
        return self.check_majorite(personne)
 
 
class Controleur(VerificateurDeMajorite):
 
    adapteurs = (
        PersonneAdapteur,
        # ProspectAdapteur()
        LeClientAdapteur(),
    )
 
    def est_autorise(self, personne):
        return self.check_majorite(personne)

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

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

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

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

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

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

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

flattr this!

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

J’ai nommé…

Les métaclasses.

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

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

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

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

Pré-requis:

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

Musique.

Au début, il y avait les objets

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

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

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

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

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

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

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

On peut l’assigner à une variable :

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

On peut le passer en paramètre :

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

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

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

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

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

Parce qu’on peut faire pareil avec les classes :

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

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

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

A oui. Classes. Dynamiques.

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

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

>>> print type(1)
<type 'int'>
>>> print type("1")
<type 'str'>
>>> print type(CreateurDObject)
<type 'type'>
>>> print type(CreateurDObject())
<class '__main__.CreateurDObject'>

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

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

Bref, ça marche comme ça :

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

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

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

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

Exemple, cette classe :

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

Peut se créer ainsi :

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

Et s’utiliser tout pareil :

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

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

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

Un petit exemple avec des attributs :

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

Ce qui donne :

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

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

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

Peut se traduire par :

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

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

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

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

Se transforme en :

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

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

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

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

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

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

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

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

Puisque les classes sont des objets ?

Vous suivez ?

Non ?

Ah.

o

En deux lignes alors :

UneClasse = MetaClass()
un_objet = UneClasse()

Mieux ?

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

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

>>> pokemon_capture = 149
>>> pokemon_capture.__class__
<type 'int'>
>>> nom = 'magicarp'
>>> nom.__class__
<type 'str'>
>>> def attrapez_les_presque_tous(): pass
>>> attrapez_les_presque_tous.__class__
<type 'function'>
>>> class Pokedex(object): pass
>>> gadget = Pokedex()
>>> gadget.__class__
<class '__main__.Pokedex'>

Mais quelle est le __class__ de tout __class__ ?

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

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

Faites “Ahhhhhhhhhhhhhhhhh”.

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

Ça marche comme ça :

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

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

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

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

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

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

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

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

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

# une métaclasse DOIT avoir la même signature que type() puisque
# Python va lui passer tout ça automatiquement en paramètre
 
def prefixer(nom, parents, attributs):
    """
        On va créer une métaclasse qui prend tous les noms de méthodes,
        et les prefixe du mot "attaque". Oui ça ne sert à rien. Mais
        les usages des métaclasses qui servent à quelques choses sont
        généralement très compliqués.
    """
 
    # On crée un nouveau dictionnaire d'attributs avec les noms préfixés
    # On fait gaffe à pas modifier les __méthodes_magique__.
    nouveaux_attributs = {}
    for nom, val in attributs.items():
        if not nom.startswith('__'):
            nouveaux_attributs['attaque_' + nom] = val
        else:
            nouveaux_attributs[nom] = val
 
    # On délègue la création de la classe à type() :
    return type(nom, parents, nouveaux_attributs)

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

>>> class Ronflex(object):
 
    __metaclass__ = prefixer
 
    def armure(self):
        print("defense +15")
 
    def dodo(self):
        print("zzzzzz")
>>> r = Ronflex()
>>> r.attaque_armure()
defense +15
>>> r.attaque_dodo()
zzzzzz
>>> r.dodo()
Traceback (most recent call last):
  File "<ipython-input-58-90dd54234d5d>", line 1, in <module>
    r.dodo()
AttributeError: 'armure' object has no attribute 'dodo'

Voilà, c’est à peut prêt tout ce qu’il y a à comprendre des métaclasses :

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

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

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

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

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

En effet, quand vous faites :

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

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

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

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

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

Soyez prophètes

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

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

class DePython3(metaclass=votre_metaclasse)

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

def prefixer(name, bases, dct):
    nouveaux_attributs = {}
    for nom, val in dct.items():
        if not nom.startswith('__'):
            nouveaux_attributs['attaque_' + nom] = val
        else:
            nouveaux_attributs[nom] = val
 
    # On délègue la création de la classe à type() :
    return type(name, bases, nouveaux_attributs)

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

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

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

# Oui, on peut hériter de type(), car c'est une classe, enfin une métaclasse.
# Mais pas sous forme de fonction. Sous forme de classe. Mais son nom
# est en minuscule, comme celui des classes int() et str(). Qui ne sont
# pas des métaclasses. Souvenez-vous : Beaujolais.
class Prefixer(type):
 
    # __new__ est le vrai constructeur en Python, et il retourne l'instance
    # en cours d'une classe. Or, qu'elle est l'instance d'une métaclasse ?
    # Une classe !
    def __new__(cls, name, bases, dct):
 
        nouveaux_attributs = {}
        for nom, val in dct.items():
            if not nom.startswith('__'):
                nouveaux_attributs['attaque_' + nom] = val
            else:
                nouveaux_attributs[nom] = val
 
        # On délègue la création de la classe à son parent.
        # Notez que cls doit être passé de bout en bout, ce qui n'est pas
        # le cas d'habitude avec 'self'
        return super(Prefixer, cls).__new__(cls, name, bases, nouveaux_attributs)

Et ça s’utilise pareil

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

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

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

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

# on hérite plus de type, rien à foutre
class Prefixer(object):
 
    def __init__(self, prefix='attaque'):
        self.prefix = prefix
 
    # __call__ est la méthode appelée automatiquement quand on ajoute () après
    # un nom d'objet. Ca permet de rendre un objet callable. En gros, ça nous
    # permet d'utiliser une instance de Prefixer() comme une fonction
    def __call__(self, name, bases, dct):
 
        nouveaux_attributs = {}
        for nom, val in dct.items():
            if not nom.startswith('__'):
                nouveaux_attributs[self.prefix + nom] = val
            else:
                nouveaux_attributs[nom] = val
 
        return type(name, bases, nouveaux_attributs)

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

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

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

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

>>> type.__class__
<type 'type'>

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

flattr this!

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

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

Comme je vous l’avais expliqué, l’orienté object 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 dossiers
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étails). Je mettrai mes commentaires entre #< sm > afin de les distinguer du reste.

 
#<sm>
# On commence par un bon gros bloc de copyright, sachant que path.py est
# sous MIT License. Le plus inhabituel c'est l'absence de déclaration
# d'encoding en en-tête, qui s'explique par le fait que toute la lib est
# écrite uniquement avec des caractères ASCII, ce qui est l'encodage par
# défaut de Python 2.7. Python 3 a UTF8 en encodage par défaut, mais ASCII
# est un sous-ensemble de UTF8, donc ça ne pose pas de problème.
 
# Notez qu'avec mes commentaires en plus, ça ferait planter le script puisque
# j'utilise des accents.
#</sm>
 
#
# Copyright (c) 2010 Mikhail Gusarov
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
#
 
#<sm>
# La docstring du module qui documente l'usage général du module. En
# l'occurence au moins l'existence de la classe principale et son usage. Les
# symboles comme '\x40' sont juste une autre représentation d'un caractères
# via sa valeur dans la table ASCII.
 
# Par exemple, '@' est à la case 64 dans la table ASCII, et 64 se note 40 en
# hexadecimal:
 
# >>> 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 peut faire passer
# du texte avec des caractères spéciaux dans certains protocole, par exemple
# quand on veut rentrer un email dans une URL. En l'occurence je ne vois
# absolument pas ce que ça vient foutre ici.
#</sm>
 
 
""" path.py - An object representing a path to a file or directory.
 
Original author:
 Jason Orendorff <jason.orendorff\x40gmail\x2ecom>
 
Current maintainer:
 Jason R. Coombs <jaraco@jaraco.com>
 
Contributors:
 Mikhail Gusarov <dottedmag@dottedmag.net>
 Marc Abramowitz <marc@marc-abramowitz.com>
 Jason R. Coombs <jaraco@jaraco.com>
 Jason Chu <jchu@xentac.net>
 Vojislav Stojkovic <vstojkovic@syntertainment.com>
 
Example::
 
    from path import path
    d = path('/home/guido/bin')
    for f in d.files('*.py'):
        f.chmod(0755)
 
path.py requires Python 2.5 or later.
"""
 
 
#<sm>
# Import du mot clé with, car cette lib est compatible avec Python 2.5
# et le keyword est apparu en 2.6. Il a été backporté dans __future__
#</sm>
from __future__ import with_statement
 
import sys #<sm>Informations sur le système</sm>
import warnings #<sm>Alertes techniques à d'autres dev</sm>
import os #<sm>Manipulation du FS</sm>
import fnmatch #<sm>Pattern matching comme dans un shell</sm>
import glob #<sm>Lister des fichier avec la syntax shell</sm>
import shutil #<sm>Manipulation de fichiers de haut niveau</sm>
import codecs #<sm>Encoding</sm>
import hashlib #<sm>Sommes de controle</sm>
import errno #<sm>Les code d'erreurs liées au fichier.</sm>
import tempfile #<sm>Création de fichiers temporaires</sm>
import functools #<sm>Manipulation des fonctions</sm>
 
#<sm>
# Tentative d'utilisation de la lib win32security qui sert à gérer
# des aspects sécuritaires du FS sous Windows. C'est une lib tièrce partie,
# et une dépendance ooptionelle, donc l'import est géré pour ne pas faire
# d'erreur si la lib n'est pas disponible.
 
# Idem pour pwd qui est dans la lib standard mais uniquement sur les distribs
# unix et qui donne accès aux infos sur l'utilisateur du système, tester
# son mot de passe, etc.
#</sm>
try:
    import win32security
except ImportError:
    pass
 
try:
    import pwd
except ImportError:
    pass
 
 
 
#<sm>
# Manière standard de lister la version de la lib dans un module Python.
 
# __all__ est une variable magique qui peut contenir une liste des noms de
# tout ce qui est importable dans le module, de telle sorte que si
# quelqu'un fait : from path import *, seul le contenu de __all__ soit
# importé.
#</sm>
__version__ = '3.0'
__all__ = ['path']
 
 
#<sm>
# Les warning ressemblent beaucoup aux exceptions excepté qu'ils ne font
# pas planter le programme. Ici donc, ou hérite de la base des warnings
# comme on le ferait pour créer son Exception personnalisée, ce qui va
# permettre à l'utilisateur de la lib path.py de, plus tard, pouvoir filter
# ce warning en particulier.
#</sm>
 
 
class TreeWalkWarning(Warning):
    pass
 
 
#<sm>
# Un decorateur de mémorisation, c'est à dire qui va mettre en cache les
# résultats de la fonction sur lequel il est appliqué afin que les prochains
# appels avec les mêmes paramètres lisent les valeurs du cache en mémoire
# plutôt que de refaire l'opération.
 
# Il est utilisé plus bas sur :
 
#     @classmethod
#     @simple_cache
#     def using_module(cls, module):
#         subclass_name = cls.__name__ + '_' + module.__name__
#         bases = (cls,)
#         ns = {'module': module}
#         return type(subclass_name, bases, ns)
 
# Ça évitera plusieurs traitements de using_module() si le paramètre de
# 'module' ne change pas.
 
# Et oui, on peut mélanger plusieurs classes et fonctions dans un même module,
# ça n'a pas d'importance.
 
#</sm>
def simple_cache(func):
    """
    Save results for the 'using_module' classmethod.
    When Python 3.2 is available, use functools.lru_cache instead.
    """
    saved_results = {}
    def wrapper(cls, module):
        if module in saved_results:
            return saved_results[module]
        saved_results[module] = func(cls, module)
        return saved_results[module]
    return wrapper
 
 
#<sm>
# Nous avons vu que les propriétés permettaient de déguiser une méthode
# en attribut. Cela ne marche pas sur une méthode de classe car dans ce cas
# la propriété va se retourner elle-même.
# Cette classe hérite de property pour écraser ce comportement et bien
# retourner la valeur de la méthode de classe.
 
# Elle est utilisée plus loin dans:
 
#     @ClassProperty
#     @classmethod
#     def _next_class(cls):
#         """
#         What class should be used to construct new instances from this class
#         """
#         return cls
 
# Ce qui va permettre de faire path._next_class au lieu de path._next_class().
 
# C'est cosmétique, mais c'est le but de la lib d'être jolie.
#</sm>
class ClassProperty(property):
    def __get__(self, cls, owner):
        return self.fget.__get__(None, owner)()
 
#<sm>
# Encore un décorateur, cette fois sous forme de classe (on ne les a pas vu)
# Celui-ci, quand il est appliqué, sert à ce qu'une méthode soit à la fois
# une méthode d'instance et une méthode de classe, le choix se faisant
# dynamiquement selon la situation.
 
# Par exemple dans:
 
#     @multimethod
#     def joinpath(cls, first, *others):
#         """
#         Join first to zero or more path components, adding a separator
#         character (first.module.sep) if needed.  Returns a new instance of
#         first._next_class.
#         """
#         if not isinstance(first, cls):
#             first = cls(first)
#         return first._next_class(first.module.join(first, *others))
 
# 'cls' sera une instance ou une classe selon que l'appel se fasse depuis la
# classe ou l'instance.
 
# Notez le nom de la classe qui n'est pas en CamelCase (pas de majuscule)
# alors qu'il s'agit bien d'un classe. Comme c'est un décorateur, on a
# l'habitude de les voire en minuscule, donc on laisse ce nom en minuscule.
# C'est une des rares exceptions au PEP8 (on en verra d'autres plus bas)
# qu'on peut se permettre quand on sait ce qu'on fait :-)
#</sm>
class multimethod(object):
    """
    Acts like a classmethod when invoked from the class and like an
    instancemethod when invoked from the instance.
    """
    def __init__(self, func):
        self.func = func
 
    def __get__(self, instance, owner):
        return (
            functools.partial(self.func, owner) if instance is None
            else functools.partial(self.func, owner, instance)
        )
 
 
#<sm>
# La classe principale, et le plus gros morceau de code. Une classe peut
# tout à fait faire plusieurs centaines de lignes.
 
# En général je recommande de ne pas avoir de fichiers qui fait plus de 500
# lignes en Python, mais ici le but est clairement de faire une lib qui tient
# dans un fichier pour l'auteur.
 
# La classe hérite du type unicode (hé oui, on peut hériter des types
# built-in !); ainsi le path peut être manipulé comme une chaîne et reste
# compatible avec tous les outils de manipulation de nom de fichiers existant
# car ils utilisent les chaînes.
 
# L'héritage est une techno qui sert donc aussi à conserver des compatibilités
# et des comportements existant / attendus.
 
# Encore une fois le nom est en minuscule alors que c'est une classe, c'est une
# autre exception : quand on créer un type de base, on le met en minuscule
# car c'est ce que fait la lib standard (int(), str(), list(), datetime(),
# unicode, etc, sont en fait des classes).
 
# La docstring pourrait être meilleure.
#</sm>
class path(unicode):
    """ Represents a filesystem path.
 
    For documentation on individual methods, consult their
    counterparts in os.path.
    """
 
    #<sm>
    # Probablement mon désaccord principal avec cette lib, l'init vérifie
    # qu'on lui passe bien une chaîne alors que j'aurais choisit le duck typing.
    #</sm>
 
    def __init__(self, other):
        if not isinstance(other, basestring):
            raise TypeError("path must be a string")
 
    #<sm>
    # L'auteur stocke la référence de os.path ici, et l'utilise partout à la
    # place d'utiliser os.path directement. Cela permet de changer ce module à
    # la volée, par exemple pour utiliser spécifiquement le module dédié à
    # Windows ou à unix au lieu de celui choisit automatiquement.
 
    # C'est un exemple de pattern stratégie.
 
    # Et non, la docstring n'a aucun effet. Ça pourrait être un comment.
    # En revanche, comme spécifié en comment, certains outils comme sphinx
    # prend les docstring en compte sur les variables.
 
    #</sm>
 
    module = os.path
    "The path module to use for path operations."
 
 
    #<sm>
    # Une méthode retourne une classe path dont le module est
    # celui passé en paramètre. Pratique si vous voulez
    # utiliser un module de spécifique à un OS depuis un autre
    # mais juste ponctuellement.
    # Par exemple sous Windows, vous voulez traiter un chemin
    # (mais un seul, le reste est sous Windows) Unix, vous
    # pouvez faire :
    #
    # >>> import posixpath
    # >>> p = path.using_module(posixpath)('/etc')
    # >>> print p
    # /etc
    # >>> p
    # path_posixpath(u'/etc')
 
    # ce qui crée un objet path() dont l'attribut 'module' est le module
    #  posixpath. C'est une application concrète de l'injection de dépendance.
 
    #</sm>
    @classmethod
    @simple_cache
    def using_module(cls, module):
        subclass_name = cls.__name__ + '_' + module.__name__
        bases = (cls,)
        ns = {'module': module}
        return type(subclass_name, bases, ns)
 
 
    #<sm>
    # Une propriété qui retourne la classe (oui, on peut retourner une CLASSE)
    # à utiliser si on veut créer une nouvelle instance de cette classe.
 
    # C'est très abstrait, vous n'aurez pas à faire ça tous les jours.
 
    # C'est une méthode placée là pour permettre un maximum de configurabilité
    # : si vous changez cette classe, certaines méthodes renverront un autre
    # type plutôt que le type en cours. Utile pour certains cas où vous voulez
    # hériter de path() mais désirez un comportement spécial pour la création
    # de nouveaux path.
    #</sm>
    @ClassProperty
    @classmethod
    def _next_class(cls):
        """
        What class should be used to construct new instances from this class
        """
        return cls
 
    # --- Special Python methods.
 
    #<sm>
    # Là on attaque la définition de toutes les méthodes magiques.
    # Essentiellement pour overrider le comportement par défaut des chaines
    # unicode et exposer une API sympas.
    #</sm>
 
 
    #<sm>
    # Dans le shell, un path s'affichera path('chemin') et non 'chemin'
    # L'auteur affiche en fait le nom du type en cours (en cas d'héritage
    # cela changera) et ensuite la representation du parent, en l'occurence
    # la classe unicode().
    #</sm>
    def __repr__(self):
        return '%s(%s)' % (type(self).__name__, super(path, self).__repr__())
 
 
    #<sm>
    # Override l'addition.
    # path('truc') + 'machin' donne path('trucmachin')
    #</sm>
    # Adding a path and a string yields a path.
    def __add__(self, more):
        try:
            return self._next_class(super(path, self).__add__(more))
        except TypeError:  # Python bug
            return NotImplemented
 
    #<sm>
    # 'machin' + path('truc') donne path('trucmachin')
    #</sm>
    def __radd__(self, other):
        if not isinstance(other, basestring):
            return NotImplemented
        return self._next_class(other.__add__(self))
 
    #<sm>
    # Override la division.
    # path('truc') / 'machin' donne path('trucm/achin')
    #</sm>
    # The / operator joins paths.
    def __div__(self, rel):
        """ fp.__div__(rel) == fp / rel == fp.joinpath(rel)
 
        Join two path components, adding a separator character if
        needed.
        """
        return self._next_class(self.module.join(self, rel))
 
    #<sm>
    # Petite astuce de compatibilité si le mec a fait
    # from __future__ import division ou si on est en Python 3
    #
    # Remarque : on peut définir des attributs de classe n'importe où, et pas
    # seulement en haut de la classe.
    #</sm>
 
    # Make the / operator work even when true division is enabled.
    __truediv__ = __div__
 
    #<sm>
    # path() est aussi un context manager qu'on peut utiliser avec with !
 
    # with path('truc'):
    #     tout ce qui est ici ce 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 '*' et l'opérateur de paramétrage dynamique. '*_' est donc l'auteur
    # signalant qu'il accepte n'importe quels paramètres positionnels, mais
    # qu'ils ne les utilisera pas.
    #</sm>
    def __enter__(self):
        self._old_dir = self.getcwd()
        os.chdir(self)
 
    def __exit__(self, *_):
        os.chdir(self._old_dir)
 
 
    #<sm>
    # Le résultat de os.getcwdu(), mais retourne un objet path().
    # Une bonne part du travail de la lib consiste à wrapper les méthodes
    # ordinaires des autres modules pour qu'elles retournent un type path()
    # pour qu'après on puisse faire des '.parent' ou utiliser '/' dessus
    # sans y penser.
    #</sm>
 
    @classmethod
    def getcwd(cls):
        """ Return the current working directory as a path object. """
        return cls(os.getcwdu())
 
    #
    # --- Operations on path strings.
 
    #<sm>
    # On enchaine ici des wrappers sur des méthodes de os.path (ou son
    # remplaçant dans self.module), que l'objet s'applique à lui-même (self).
    # Comme la classe hérite de 'unicode', toutes ces méthodes marchent.
    # Et comme self._next_class retourne la classe pour créer le prochain
    # path, on retourne toujours un objet de type 'path'.
 
    # Si on fait fi des abstractions et qu'on lit les valeurs par défaut,
 
    #     self._next_class(self.module.abspath(self))
 
    # fait en fait:
 
    #     path(os.path.abspath('ton_chemin'))
 
    # Ce qui donne l'API suivante quand on utilise la lib :
 
    #     >>> path('/etc/nginx/..').abspath()
    #     path(u'/etc')
    #</sm>
 
    def abspath(self):
        return self._next_class(self.module.abspath(self))
 
    def normcase(self):
        return self._next_class(self.module.normcase(self))
 
    def normpath(self):
        return self._next_class(self.module.normpath(self))
 
    def realpath(self):
        return self._next_class(self.module.realpath(self))
 
    def expanduser(self):
        return self._next_class(self.module.expanduser(self))
 
    def expandvars(self):
        return self._next_class(self.module.expandvars(self))
 
    def dirname(self):
        return self._next_class(self.module.dirname(self))
 
    def basename(self):
        return self._next_class(self.module.basename(self))
 
 
    #<sm>
    # Là on rentre dans les méthodes utilitaires. L'auteur a constaté qu'on
    # appelait très souvent ces trois méthodes sur les chemin des fichiers de
    # config genre '~/toto' pour obtenir '/home/sam/toto' et propose donc
    # un shortcut pour le faire car honnêtement, qui se souvient du nom
    # de ces 3 méthodes à enchaîner pour obtenir un truc bullet proof ?
    # Règle d'or d'une belle API : si il faut regarder dans la doc à chaque
    # fois qu'on utilise quelque chose, il faut écrire un meilleur code.
    #</sm>
 
    def expand(self):
        """ Clean up a filename by calling expandvars(),
        expanduser(), and normpath() on it.
 
        This is commonly everything needed to clean up a filename
        read from a configuration file, for example.
        """
        return self.expandvars().expanduser().normpath()
 
 
    #<sm>
    # Les méthodes suivantes sont préfixées d'un '_', donc elle n'apparaitront
    # pas dans les résultats d'outils avec complétion du code. Cela nous
    # indique qu'il s'agit d'un détail 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.
 
    # Ce 3 méthodes retournent respectivement l'extension de fichier, le nom
    # de fichier sans extension, et la lettre de lecteur sur les chemins
    # windows.
    #</sm>
 
    def _get_namebase(self):
        base, ext = self.module.splitext(self.name)
        return base
 
    def _get_ext(self):
        f, ext = self.module.splitext(self)
        return ext
 
    def _get_drive(self):
        drive, r = self.module.splitdrive(self)
        return self._next_class(drive)
 
 
    #<sm>
 
    # Malgré l'indentation bizarre, il s'agit bien de :
 
    #     attribut_de_classe = function(arg1, arg2, arg3, arg4)
 
 
    # Dans les tutos précédents vous avez vu comment créer une propriété avec
    # le décorateur @property.
 
    # Ici l'auteur utilise l'ancienne façon de faire, car il veut garder la
    # compatibilité avec python 2.5.
 
    # C'est globalement la même chose, par exemple ici l'attribut 'namebase'
    # est défini comme une property et y accéder en lecture va appeler la
    # méthode '_get_namebase'. Le second et le troisième argument de
    # property() sont les setter et les deleter qui ne sont pas ici définis et
    # mis à None (donc l'attribut est en lecture seule). Le dernier argument
    # est la docstring.
 
    #</sm>
 
    parent = property(
        dirname, None, None,
        """ This path's parent directory, as a new path object.
 
        For example, path('/usr/local/lib/libpython.so').parent == path('/usr/local/lib')
        """)
 
    name = property(
        basename, None, None,
        """ The name of this file or directory without the full path.
 
        For example, path('/usr/local/lib/libpython.so').name == 'libpython.so'
        """)
 
    namebase = property(
        _get_namebase, None, None,
        """ The same as path.name, but with one file extension stripped off.
 
        For example, path('/home/guido/python.tar.gz').name     == 'python.tar.gz',
        but          path('/home/guido/python.tar.gz').namebase == 'python.tar'
        """)
 
    ext = property(
        _get_ext, None, None,
        """ The file extension, for example '.py'. """)
 
    drive = property(
        _get_drive, None, None,
        """ The drive specifier, for example 'C:'.
        This is always empty on systems that don't use drive specifiers.
        """)
 
    #<sm>
    # Encore des wrappers pour retourner des objets path(). La structure
    # est classique: définition de méthodes courtes avec docstring.
 
    # L'auteur retourne un tuple comme les méthodes originales (autant
    # changer le comportement attendu le moins possible), mais cast la
    # première partie du tuple en objet path().
    #</sm>
 
    def splitpath(self):
        """ p.splitpath() -> Return (p.parent, p.name). """
        parent, child = self.module.split(self)
        return self._next_class(parent), child
 
    def splitdrive(self):
        """ p.splitdrive() -> Return (p.drive, <the rest of p>).
 
        Split the drive specifier from this path.  If there is
        no drive specifier, p.drive is empty, so the return value
        is simply (path(''), p).  This is always the case on Unix.
        """
        drive, rel = self.module.splitdrive(self)
        return self._next_class(drive), rel
 
    def splitext(self):
        """ p.splitext() -> Return (p.stripext(), p.ext).
 
        Split the filename extension from this path and return
        the two parts.  Either part may be empty.
 
        The extension is everything from '.' to the end of the
        last path segment.  This has the property that if
        (a, b) == p.splitext(), then a + b == p.
        """
        filename, ext = self.module.splitext(self)
        return self._next_class(filename), ext
 
    #<sm>
    # Ici on a des méthodes légèrement différentes de celles qu'elles wraps.
    # C'est vraiment pour se faciliter la tâche sur les opérations courantes
    # et sauver quelques caractères à la frappe.
    #</sm>
 
    def stripext(self):
        """ p.stripext() -> Remove one file extension from the path.
 
        For example, path('/home/guido/python.tar.gz').stripext()
        returns path('/home/guido/python.tar').
        """
        return self.splitext()[0]
 
    def splitunc(self):
        unc, rest = self.module.splitunc(self)
        return self._next_class(unc), rest
 
    @property
    def uncshare(self):
        """
        The UNC mount point for this path.
        This is empty for paths on local drives.
        """
        unc, r = self.module.splitunc(self)
        return self._next_class(unc)
 
    #<sm>
    # joinpath cast le premier argument si il n'est pas du même type que la
    # classe en cours. Il n'y a pas de raison apparente, donc je suppose que
    # c'est pour éviter une bug qu'ils ont découvert dans une situation
    # borderline
    #</sm>
 
    @multimethod
    def joinpath(cls, first, *others):
        """
        Join first to zero or more path components, adding a separator
        character (first.module.sep) if needed.  Returns a new instance of
        first._next_class.
        """
        if not isinstance(first, cls):
            first = cls(first)
        return first._next_class(first.module.join(first, *others))
 
 
    #<sm>
    # Puis on arrive enfin dans les méthodes métiers qui ne sont pas dans les
    # modules. Typiquement ce seront des méthodes plus longues et inconnues
    # car n'existant pas dans les autres modules donc :
    # - on les met à la fin
    # - la docstring est plus explicite.
    # Ici splitall permet de faire :
 
    # >>> path('/usr/lib/python2.7/fnmatch.pyc').splitall()
    # [path(u'/'), u'usr', u'lib', u'python2.7', u'fnmatch.pyc']
 
    # Ce que os.path ne permet pas de faire directement.
 
    #</sm>
 
    def splitall(self):
        r""" Return a list of the path components in this path.
 
        The first item in the list will be a path.  Its value will be
        either os.curdir, os.pardir, empty, or the root directory of
        this path (for example, ``'/'`` or ``'C:\\'``).  The other items in
        the list will be strings.
 
        ``path.path.joinpath(*result)`` will yield the original path.
        """
        parts = []
        loc = self
        while loc != os.curdir and loc != os.pardir:
            prev = loc
            loc, child = prev.splitpath()
            if loc == prev:
                break
            parts.append(child)
        parts.append(loc)
        parts.reverse()
        return parts
 
 
    #<sm>
 
    # Voici une bonne pratique, avoir une méthode complexe (ici relpathto(),
    # qui créer un chemin relatif du path() courant vers un autre dossier), et
    # son opposée plus simple (ici relpath(), qui créer un chemin relatif d'un
    # dossier vers le path courant) qui utilise la méthode précédente en en
    # inversant juste les paramètres.
 
    # En effet ça ne sert à rien d'écrire deux fois la même méthode, on
    # factorise ainsi du code et respecte le principe DRY (don't repeat
    # yourself).
 
    # relpathto() est un bon exemple d'un code assez complexe pour une
    # opération qui parait pourtant assez simple. C'est aussi un très bon
    # exemple de comment écrire des commentaires : on ne décrit pas les
    # opérations évidentes mais on explique les choses ambiguës et on met des
    # avertissements
 
    #</sm>
 
    def relpath(self, start='.'):
        """ Return this path as a relative path,
        based from start, which defaults to the current working directory.
        """
        cwd = self._next_class(start)
        return cwd.relpathto(self)
 
    def relpathto(self, dest):
        """ Return a relative path from self to dest.
 
        If there is no relative path from self to dest, for example if
        they reside on different drives in Windows, then this returns
        dest.abspath().
        """
        origin = self.abspath()
        dest = self._next_class(dest).abspath()
 
        orig_list = origin.normcase().splitall()
        # Don't normcase dest!  We want to preserve the case.
        dest_list = dest.splitall()
 
        if orig_list[0] != self.module.normcase(dest_list[0]):
            # Can't get here from there.
            return dest
 
        # Find the location where the two paths start to differ.
        i = 0
        for start_seg, dest_seg in zip(orig_list, dest_list):
            if start_seg != self.module.normcase(dest_seg):
                break
            i += 1
 
        # Now i is the point where the two paths diverge.
        # Need a certain number of "os.pardir"s to work up
        # from the origin to the point of divergence.
        segments = [os.pardir] * (len(orig_list) - i)
        # Need to add the diverging part of dest_list.
        segments += dest_list[i:]
        if len(segments) == 0:
            # If they happen to be identical, use os.curdir.
            relpath = os.curdir
        else:
            relpath = self.module.join(*segments)
        return self._next_class(relpath)
 
    # --- Listing, searching, walking, and matching
 
    #<sm>
    # un simple wrapper mais qui rajoute un argument en plus : un pattern à la
    # unix. C'est une extension naturelle, et c'est le genre de chose que vous
    # voudrez faire quand vous vous êtes toujours demandé : "mais pourquoi
    # c'est pas par défaut ?" ou "comment on fait ça facilement ?" Si vous
    # vous posez ce genre de question, étendez un peu les comportements
    # initiaux. Rajouter un argument ne rend pas le comportement différent du
    # précédent grâce au paramètre par défaut mis à None, donc c'est tout
    # bénef.
    #</sm>
 
    def listdir(self, pattern=None):
        """ D.listdir() -> List of items in this directory.
 
        Use D.files() or D.dirs() instead if you want a listing
        of just files or just subdirectories.
 
        The elements of the list are path objects.
 
        With the optional 'pattern' argument, this only lists
        items whose names match the given pattern.
        """
        names = os.listdir(self)
        if pattern is not None:
            names = fnmatch.filter(names, pattern)
        return [self / child for child in names]
 
    #<sm>
    # Dans la même lignée de ce qu'on a vu plus haut: utiliser une fonction
    # plus complexe (qui déjà étend un comportement par défaut) pour en
    # faire encore une méthode plus spécialisée.
 
    # L'avantage de cette approche c'est que le code est plein de petites
    # briques:
 
    # vous avez listdir(), qui est assez court (mais déjà plus puissant),
    # puis dirs() et files(), qui font la même chose en plus spécialisés.
 
    # L'alternative aurait été d'ajouter une param à listdir() et ne pas
    # créer dirs() et files(), mais ça aurait rajouté un if dans le code et
    # un paramètre qui fait rechercher dans la doc celui qui l'utilise et
    # celui qui lit le code.
 
    # Avec l'approche actuelle, l'API est très claire :
 
    # for d in path('/etc').dirs()
 
    # On s'attend à lire tous les dossiers de /etc. Et les
    # méthodes restent courtes.
 
    #</sm>
 
    def dirs(self, pattern=None):
        """ D.dirs() -> List of this directory's subdirectories.
 
        The elements of the list are path objects.
        This does not walk recursively into subdirectories
        (but see path.walkdirs).
 
        With the optional 'pattern' argument, this only lists
        directories whose names match the given pattern.  For
        example, ``d.dirs('build-*')``.
        """
        return [p for p in self.listdir(pattern) if p.isdir()]
 
    def files(self, pattern=None):
        """ D.files() -> List of the files in this directory.
 
        The elements of the list are path objects.
        This does not walk into subdirectories (see path.walkfiles).
 
        With the optional 'pattern' argument, this only lists files
        whose names match the given pattern.  For example,
        ``d.files('*.pyc')``.
        """
 
        return [p for p in self.listdir(pattern) if p.isfile()]
 
 
    #<sm>
 
    # walk() et ses pendants walkdirs() et walkfiles() sont des alternatives
    # au très peu intuitif os.path.walk qui permet de traverser récursivement
    # un répertoire.
 
    # En effet, en Python les callbacks sont quelque chose qu'on utilise peu,
    # et à l'inverse, on itère beaucoup.
 
    # Cela permet de faire:
 
    # for f in path('/etc').walk_files():
 
    # Pour lister récursivements 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 algorythme 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 parmis :
 
    # - lever une exception (qui est dans un code propre le choix par défaut)
    # - ignorer (pour faire un code tolérant aux erreur)
    # - 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'utilise pas walk(), ce qui est généralement fait pour des raisons de
    # performances (on sacrifie le DRY pour éviter un appel de callback
    # ou un test sur des grosses boucles), même si ici c'est une supposition.
 
    #</sm>
 
    def walk(self, pattern=None, errors='strict'):
        """ D.walk() -> iterator over files and subdirs, recursively.
 
        The iterator yields path objects naming each child item of
        this directory and its descendants.  This requires that
        D.isdir().
 
        This performs a depth-first traversal of the directory tree.
        Each directory is returned just before all its children.
 
        The errors= keyword argument controls behavior when an
        error occurs.  The default is 'strict', which causes an
        exception.  The other allowed values are 'warn', which
        reports the error via warnings.warn(), and 'ignore'.
        """
        if errors not in ('strict', 'warn', 'ignore'):
            raise ValueError("invalid errors parameter")
 
        try:
            childList = self.listdir()
        except Exception:
            if errors == 'ignore':
                return
            elif errors == 'warn':
                warnings.warn(
                    "Unable to list directory '%s': %s"
                    % (self, sys.exc_info()[1]),
                    TreeWalkWarning)
                return
            else:
                raise
 
        for child in childList:
            if pattern is None or child.fnmatch(pattern):
                yield child
            try:
                isdir = child.isdir()
            except Exception:
                if errors == 'ignore':
                    isdir = False
                elif errors == 'warn':
                    warnings.warn(
                        "Unable to access '%s': %s"
                        % (child, sys.exc_info()[1]),
                        TreeWalkWarning)
                    isdir = False
                else:
                    raise
 
            if isdir:
                for item in child.walk(pattern, errors):
                    yield item
 
    def walkdirs(self, pattern=None, errors='strict'):
        """ D.walkdirs() -> iterator over subdirs, recursively.
 
        With the optional 'pattern' argument, this yields only
        directories whose names match the given pattern.  For
        example, ``mydir.walkdirs('*test')`` yields only directories
        with names ending in 'test'.
 
        The errors= keyword argument controls behavior when an
        error occurs.  The default is 'strict', which causes an
        exception.  The other allowed values are 'warn', which
        reports the error via warnings.warn(), and 'ignore'.
        """
        if errors not in ('strict', 'warn', 'ignore'):
            raise ValueError("invalid errors parameter")
 
        try:
            dirs = self.dirs()
        except Exception:
            if errors == 'ignore':
                return
            elif errors == 'warn':
                warnings.warn(
                    "Unable to list directory '%s': %s"
                    % (self, sys.exc_info()[1]),
                    TreeWalkWarning)
                return
            else:
                raise
 
        for child in dirs:
            if pattern is None or child.fnmatch(pattern):
                yield child
            for subsubdir in child.walkdirs(pattern, errors):
                yield subsubdir
 
    def walkfiles(self, pattern=None, errors='strict'):
        """ D.walkfiles() -> iterator over files in D, recursively.
 
        The optional argument, pattern, limits the results to files
        with names that match the pattern.  For example,
        ``mydir.walkfiles('*.tmp')`` yields only files with the .tmp
        extension.
        """
        if errors not in ('strict', 'warn', 'ignore'):
            raise ValueError("invalid errors parameter")
 
        try:
            childList = self.listdir()
        except Exception:
            if errors == 'ignore':
                return
            elif errors == 'warn':
                warnings.warn(
                    "Unable to list directory '%s': %s"
                    % (self, sys.exc_info()[1]),
                    TreeWalkWarning)
                return
            else:
                raise
 
        for child in childList:
            try:
                isfile = child.isfile()
                isdir = not isfile and child.isdir()
            except:
                if errors == 'ignore':
                    continue
                elif errors == 'warn':
                    warnings.warn(
                        "Unable to access '%s': %s"
                        % (self, sys.exc_info()[1]),
                        TreeWalkWarning)
                    continue
                else:
                    raise
 
            if isfile:
                if pattern is None or child.fnmatch(pattern):
                    yield child
            elif isdir:
                for f in child.walkfiles(pattern, errors):
                    yield f
 
    def fnmatch(self, pattern):
        """ Return True if self.name matches the given pattern.
 
        pattern - A filename pattern with wildcards,
            for example ``'*.py'``.
        """
        return fnmatch.fnmatch(self.name, pattern)
 
    def glob(self, pattern):
        """ Return a list of path objects that match the pattern.
 
        pattern - a path relative to this directory, with wildcards.
 
        For example, path('/users').glob('*/bin/*') returns a list
        of all the files users have in their bin directories.
        """
        cls = self._next_class
        return [cls(s) for s in glob.glob(self / pattern)]
 
    #
    # --- Reading or writing an entire file at once.
 
    def open(self, mode='r'):
        """ Open this file.  Return a file object. """
        return open(self, mode)
 
    #<sm>
 
    # L'avantage d'avoir une classe comme point de départ de tout c'est que
    # c'est facile à manipuler dans le shell, surtout en autocompletion.
 
    # Donc il est bon de mettre quelques outils qui sont pratiques dans les
    # usages type shell.
 
    # Ici c'est exactement le cas : on fait des méthodes un peu bourrines (
    # globalement ça dump en mémoire ou ça écrit tout le fichier d'un coup),
    # mais très pratiques pour manipuler les objets dans un terminal.
 
    # Notez aussi le nettoyage opéré:
 
    #             return (t.replace(u'\r\n', u'\n')
    #                  .replace(u'\r\x85', u'\n')
    #                  .replace(u'\r', u'\n')
    #                  .replace(u'\x85', u'\n')
    #                  .replace(u'\u2028', u'\n'))
 
    # Ce n'est pas particulièrement lié à la POO, mais l'encapsulation de
    # ce genre de process est toujours le bienvenu. L'idée est que l'objet
    # puisse être utilisé comme une boîte noire en laquelle on a totalement
    # confiance.
 
    #</sm>
 
 
    def bytes(self):
        """ Open this file, read all bytes, return them as a string. """
        with self.open('rb') as f:
            return f.read()
 
    def write_bytes(self, bytes, append=False):
        """ Open this file and write the given bytes to it.
 
        Default behavior is to overwrite any existing file.
        Call p.write_bytes(bytes, append=True) to append instead.
        """
        if append:
            mode = 'ab'
        else:
            mode = 'wb'
        with self.open(mode) as f:
            f.write(bytes)
 
    def text(self, encoding=None, errors='strict'):
        r""" Open this file, read it in, return the content as a string.
 
        This method uses 'U' mode, so '\r\n' and '\r' are automatically
        translated to '\n'.
 
        Optional arguments:
 
        encoding - The Unicode encoding (or character set) of
            the file.  If present, the content of the file is
            decoded and returned as a unicode object; otherwise
            it is returned as an 8-bit str.
        errors - How to handle Unicode errors; see help(str.decode)
            for the options.  Default is 'strict'.
        """
        if encoding is None:
            # 8-bit
            with self.open('U') as f:
                return f.read()
        else:
            # Unicode
            with codecs.open(self, 'r', encoding, errors) as f:
                # (Note - Can't use 'U' mode here, since codecs.open
                # doesn't support 'U' mode.)
                t = f.read()
            return (t.replace(u'\r\n', u'\n')
                     .replace(u'\r\x85', u'\n')
                     .replace(u'\r', u'\n')
                     .replace(u'\x85', u'\n')
                     .replace(u'\u2028', u'\n'))
 
    #<sm>
    # Sur des methodes avec de nombreux paramètres, ne pas hésiter
    # à mettre un maximum de valeurs par défaut "saines" (c'est à dire la
    # valeur du cas le plus courant ou pragmatique).
 
    # Comme c'est une grosse fonction très configurable, la docstring
    # est écrite en conséquence. Ne soyez pas timide avec la dosctring,
    # on peut la faire très très très longue, ce n'est pas une mauvaise
    # chose.
 
    # Notez que la docstring est préfixée d'un "r" ici, pour que Python
    # n'interprète pas les \n et \r.
    #</sm>
 
    def write_text(self, text, encoding=None, errors='strict', linesep=os.linesep, append=False):
        r""" Write the given text to this file.
 
        The default behavior is to overwrite any existing file;
        to append instead, use the 'append=True' keyword argument.
 
        There are two differences between path.write_text() and
        path.write_bytes(): newline handling and Unicode handling.
        See below.
 
        Parameters:
 
          - text - str/unicode - The text to be written.
 
          - encoding - str - The Unicode encoding that will be used.
            This is ignored if 'text' isn't a Unicode string.
 
          - errors - str - How to handle Unicode encoding errors.
            Default is 'strict'.  See help(unicode.encode) for the
            options.  This is ignored if 'text' isn't a Unicode
            string.
 
          - linesep - keyword argument - str/unicode - The sequence of
            characters to be used to mark end-of-line.  The default is
            os.linesep.  You can also specify None; this means to
            leave all newlines as they are in 'text'.
 
          - append - keyword argument - bool - Specifies what to do if
            the file already exists (True: append to the end of it;
            False: overwrite it.)  The default is False.
 
 
        --- Newline handling.
 
        write_text() converts all standard end-of-line sequences
        ('\n', '\r', and '\r\n') to your platform's default end-of-line
        sequence (see os.linesep; on Windows, for example, the
        end-of-line marker is '\r\n').
 
        If you don't like your platform's default, you can override it
        using the 'linesep=' keyword argument.  If you specifically want
        write_text() to preserve the newlines as-is, use 'linesep=None'.
 
        This applies to Unicode text the same as to 8-bit text, except
        there are three additional standard Unicode end-of-line sequences:
        u'\x85', u'\r\x85', and u'\u2028'.
 
        (This is slightly different from when you open a file for
        writing with fopen(filename, "w") in C or open(filename, 'w')
        in Python.)
 
 
        --- Unicode
 
        If 'text' isn't Unicode, then apart from newline handling, the
        bytes are written verbatim to the file.  The 'encoding' and
        'errors' arguments are not used and must be omitted.
 
        If 'text' is Unicode, it is first converted to bytes using the
        specified 'encoding' (or the default encoding if 'encoding'
        isn't specified).  The 'errors' argument applies only to this
        conversion.
 
        """
        if isinstance(text, unicode):
            if linesep is not None:
                # Convert all standard end-of-line sequences to
                # ordinary newline characters.
                text = (text.replace(u'\r\n', u'\n')
                            .replace(u'\r\x85', u'\n')
                            .replace(u'\r', u'\n')
                            .replace(u'\x85', u'\n')
                            .replace(u'\u2028', u'\n'))
                text = text.replace(u'\n', linesep)
            if encoding is None:
                encoding = sys.getdefaultencoding()
            bytes = text.encode(encoding, errors)
        else:
            # It is an error to specify an encoding if 'text' is
            # an 8-bit string.
            assert encoding is None
 
            if linesep is not None:
                text = (text.replace('\r\n', '\n')
                            .replace('\r', '\n'))
                bytes = text.replace('\n', linesep)
 
        self.write_bytes(bytes, append)
 
    def lines(self, encoding=None, errors='strict', retain=True):
        r""" Open this file, read all lines, return them in a list.
 
        Optional arguments:
            encoding - The Unicode encoding (or character set) of
                the file.  The default is None, meaning the content
                of the file is read as 8-bit characters and returned
                as a list of (non-Unicode) str objects.
            errors - How to handle Unicode errors; see help(str.decode)
                for the options.  Default is 'strict'
            retain - If true, retain newline characters; but all newline
                character combinations ('\r', '\n', '\r\n') are
                translated to '\n'.  If false, newline characters are
                stripped off.  Default is True.
 
        This uses 'U' mode.
        """
        if encoding is None and retain:
            with self.open('U') as f:
                return f.readlines()
        else:
            return self.text(encoding, errors).splitlines(retain)
 
    def write_lines(self, lines, encoding=None, errors='strict',
                    linesep=os.linesep, append=False):
        r""" Write the given lines of text to this file.
 
        By default this overwrites any existing file at this path.
 
        This puts a platform-specific newline sequence on every line.
        See 'linesep' below.
 
        lines - A list of strings.
 
        encoding - A Unicode encoding to use.  This applies only if
            'lines' contains any Unicode strings.
 
        errors - How to handle errors in Unicode encoding.  This
            also applies only to Unicode strings.
 
        linesep - The desired line-ending.  This line-ending is
            applied to every line.  If a line already has any
            standard line ending ('\r', '\n', '\r\n', u'\x85',
            u'\r\x85', u'\u2028'), that will be stripped off and
            this will be used instead.  The default is os.linesep,
            which is platform-dependent ('\r\n' on Windows, '\n' on
            Unix, etc.)  Specify None to write the lines as-is,
            like file.writelines().
 
        Use the keyword argument append=True to append lines to the
        file.  The default is to overwrite the file.  Warning:
        When you use this with Unicode data, if the encoding of the
        existing data in the file is different from the encoding
        you specify with the encoding= parameter, the result is
        mixed-encoding data, which can really confuse someone trying
        to read the file later.
        """
        if append:
            mode = 'ab'
        else:
            mode = 'wb'
        with self.open(mode) as f:
            for line in lines:
                isUnicode = isinstance(line, unicode)
                if linesep is not None:
                    # Strip off any existing line-end and add the
                    # specified linesep string.
                    if isUnicode:
                        if line[-2:] in (u'\r\n', u'\x0d\x85'):
                            line = line[:-2]
                        elif line[-1:] in (u'\r', u'\n',
                                           u'\x85', u'\u2028'):
                            line = line[:-1]
                    else:
                        if line[-2:] == '\r\n':
                            line = line[:-2]
                        elif line[-1:] in ('\r', '\n'):
                            line = line[:-1]
                    line += linesep
                if isUnicode:
                    if encoding is None:
                        encoding = sys.getdefaultencoding()
                    line = line.encode(encoding, errors)
                f.write(line)
 
    def read_md5(self):
        """ Calculate the md5 hash for this file.
 
        This reads through the entire file.
        """
        return self.read_hash('md5')
 
    def _hash(self, hash_name):
        with self.open('rb') as f:
            m = hashlib.new(hash_name)
            while True:
                d = f.read(8192)
                if not d:
                    break
                m.update(d)
            return m
 
    def read_hash(self, hash_name):
        """ Calculate given hash for this file.
 
        List of supported hashes can be obtained from hashlib package. This
        reads the entire file.
        """
        return self._hash(hash_name).digest()
 
    def read_hexhash(self, hash_name):
        """ Calculate given hash for this file, returning hexdigest.
 
        List of supported hashes can be obtained from hashlib package. This
        reads the entire file.
        """
        return self._hash(hash_name).hexdigest()
 
 
 
    #<sm>
    # Comme les fonctions, les méthodes peuvent être définies sur une ligne si
    # le bloc ne fait qu'une ligne de taille. On utilise ça quand la fonction
    # est juste un alias un peu avancé comme ici pour garder un style quasi
    # déclaratif.
    #</sm>
 
    # --- Methods for querying the filesystem.
    # N.B. On some platforms, the os.path functions may be implemented in C
    # (e.g. isdir on Windows, Python 3.2.2), and compiled functions don't get
    # bound. Playing it safe and wrapping them all in method calls.
 
    def isabs(self): return self.module.isabs(self)
    def exists(self): return self.module.exists(self)
    def isdir(self): return self.module.isdir(self)
    def isfile(self): return self.module.isfile(self)
    def islink(self): return self.module.islink(self)
    def ismount(self): return self.module.ismount(self)
 
    def samefile(self): return self.module.samefile(self)
 
    def getatime(self): return self.module.getatime(self)
    atime = property(
        getatime, None, None,
        """ Last access time of the file. """)
 
    def getmtime(self): return self.module.getmtime(self)
    mtime = property(
        getmtime, None, None,
        """ Last-modified time of the file. """)
 
    def getctime(self): return self.module.getctime(self)
    ctime = property(
        getctime, None, None,
        """ Creation time of the file. """)
 
    def getsize(self): return self.module.getsize(self)
    size = property(
        getsize, None, None,
        """ Size of the file, in bytes. """)
 
    #<sm>
    # Technique intéressante : on peut générer dynamiquement le corps de
    # la classe. En effet, il peut contenir des if, des try, des for, etc.
    # Ici par exemple, on ne définit la méthode access() que si le module
    # 'os' possède l'attribut 'access'.
 
    # Si ce n'est pas la cas, la classe n'aura pas cette méthode.
    #</sm>
 
    if hasattr(os, 'access'):
        def access(self, mode):
            """ Return true if current user has access to this path.
 
            mode - One of the constants os.F_OK, os.R_OK, os.W_OK, os.X_OK
            """
            return os.access(self, mode)
 
    def stat(self):
        """ Perform a stat() system call on this path. """
        return os.stat(self)
 
    def lstat(self):
        """ Like path.stat(), but do not follow symbolic links. """
        return os.lstat(self)
 
 
    #<sm>
    # Une autre technique intéressante : une des rares utilisation du double
    # '_' en tant que préfixe qui ait du sens. '__method' interdit d'accéder
    # directement à la méthode depuis l'extérieur. C'est ce qu'on a de plus
    # proche de "private" en Python.
 
    # Ce n'est pas sécurisé du tout (on peut le contourner) et cela empêche le
    # monkey patching et autres mesures de contournement en cas de besoin,
    # donc je ne vous  recommande pas de le faire.
 
    # Mais dans ce cas, ces méthodes sont volontairement définies ainsi pour
    # être invisibles puis un peu plus pas, 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: un pour windows, une pour unix et
    # une pour le cas où aucun module n'est présent) pour la même
    # fonctionnalitéé, et l'une des 3 méthodes est utilisée comme
    # implémentation de get_owner().
 
    # On aurait pu tout mettre dans des if directement, mais ça ferait des
    # gros blocs moins lisibles. Ici il est facile de comprendre le code
    # source.
    #</sm>
 
    def __get_owner_windows(self):
        r"""
        Return the name of the owner of this file or directory. Follow
        symbolic links.
 
        Return a name of the form ur'DOMAIN\User Name'; may be a group.
        """
        desc = win32security.GetFileSecurity(
            self, win32security.OWNER_SECURITY_INFORMATION)
        sid = desc.GetSecurityDescriptorOwner()
        account, domain, typecode = win32security.LookupAccountSid(None, sid)
        return domain + u'\\' + account
 
    def __get_owner_unix(self):
        """
        Return the name of the owner of this file or directory. Follow
        symbolic links.
        """
        st = self.stat()
        return pwd.getpwuid(st.st_uid).pw_name
 
    def __get_owner_not_implemented(self):
        raise NotImplementedError("Ownership not available on this platform.")
 
    if 'win32security' in globals():
        get_owner = __get_owner_windows
    elif 'pwd' in globals():
        get_owner = __get_owner_unix
    else:
        get_owner = __get_owner_not_implemented
 
    owner = property(
        get_owner, None, None,
        """ Name of the owner of this file or directory. """)
 
    if hasattr(os, 'statvfs'):
        def statvfs(self):
            """ Perform a statvfs() system call on this path. """
            return os.statvfs(self)
 
    if hasattr(os, 'pathconf'):
        def pathconf(self, name):
            return os.pathconf(self, name)
 
 
    #<sm>
    # Pas d'autres commentaires après celui-là. jusqu'à la classe de fin.
 
    # Les méthodes suivantes retournent 'self' bien que ce ne soit
    # pas nécessaire.
    # Par exemple path('/tmp/test').chmod(777) va retourner path('/tmp/test')
    # alors que tout ce qu'on lui demande, c'est de changer la permission
    # du dossier. On le fait pour permettre le chaîning, c'est à dire
    # d'autoriser les appels enchainés comme :
    # path('/tmp/test').chmod(777).rename('/tmp/essai').mkdir('ping')
    #</sm>
 
    #
    # --- Modifying operations on files and directories
 
    def utime(self, times):
        """ Set the access and modified times of this file. """
        os.utime(self, times)
        return self
 
    def chmod(self, mode):
        os.chmod(self, mode)
        return self
 
    if hasattr(os, 'chown'):
        def chown(self, uid, gid):
            os.chown(self, uid, gid)
            return self
 
    def rename(self, new):
        os.rename(self, new)
        return self._next_class(new)
 
    def renames(self, new):
        os.renames(self, new)
        return self._next_class(new)
 
    #
    # --- Create/delete operations on directories
 
    def mkdir(self, mode=0777):
        os.mkdir(self, mode)
        return self
 
    def mkdir_p(self, mode=0777):
        try:
            self.mkdir(mode)
        except OSError, e:
            if e.errno != errno.EEXIST:
                raise
        return self
 
    def makedirs(self, mode=0777):
        os.makedirs(self, mode)
        return self
 
    def makedirs_p(self, mode=0777):
        try:
            self.makedirs(mode)
        except OSError, e:
            if e.errno != errno.EEXIST:
                raise
        return self
 
    def rmdir(self):
        os.rmdir(self)
        return self
 
    def rmdir_p(self):
        try:
            self.rmdir()
        except OSError, e:
            if e.errno != errno.ENOTEMPTY and e.errno != errno.EEXIST:
                raise
        return self
 
    def removedirs(self):
        os.removedirs(self)
        return self
 
    def removedirs_p(self):
        try:
            self.removedirs()
        except OSError, e:
            if e.errno != errno.ENOTEMPTY and e.errno != errno.EEXIST:
                raise
        return self
 
    # --- Modifying operations on files
 
    def touch(self):
        """ Set the access/modified times of this file to the current time.
        Create the file if it does not exist.
        """
        fd = os.open(self, os.O_WRONLY | os.O_CREAT, 0666)
        os.close(fd)
        os.utime(self, None)
        return self
 
    def remove(self):
        os.remove(self)
        return self
 
    def remove_p(self):
        try:
            self.unlink()
        except OSError, e:
            if e.errno != errno.ENOENT:
                raise
        return self
 
    def unlink(self):
        os.unlink(self)
        return self
 
    def unlink_p(self):
        self.remove_p()
        return self
 
    # --- Links
 
    if hasattr(os, 'link'):
        def link(self, newpath):
            """ Create a hard link at 'newpath', pointing to this file. """
            os.link(self, newpath)
            return self._next_class(newpath)
 
    if hasattr(os, 'symlink'):
        def symlink(self, newlink):
            """ Create a symbolic link at 'newlink', pointing here. """
            os.symlink(self, newlink)
            return self._next_class(newlink)
 
    if hasattr(os, 'readlink'):
        def readlink(self):
            """ Return the path to which this symbolic link points.
 
            The result may be an absolute or a relative path.
            """
            return self._next_class(os.readlink(self))
 
        def readlinkabs(self):
            """ Return the path to which this symbolic link points.
 
            The result is always an absolute path.
            """
            p = self.readlink()
            if p.isabs():
                return p
            else:
                return (self.parent / p).abspath()
 
    #
    # --- High-level functions from shutil
 
    copyfile = shutil.copyfile
    copymode = shutil.copymode
    copystat = shutil.copystat
    copy = shutil.copy
    copy2 = shutil.copy2
    copytree = shutil.copytree
    if hasattr(shutil, 'move'):
        move = shutil.move
    rmtree = shutil.rmtree
 
    def rmtree_p(self):
        try:
            self.rmtree()
        except OSError, e:
            if e.errno != errno.ENOENT:
                raise
        return self
 
    #
    # --- Special stuff from os
 
    if hasattr(os, 'chroot'):
        def chroot(self):
            os.chroot(self)
 
    if hasattr(os, 'startfile'):
        def startfile(self):
            os.startfile(self)
            return self
 
 
#<sm>
# La seule spécificité de cette classe est d'overrider la méthode __new__ qui
# est le véritable constructeur en Python (__init__ n'est pas un constructeur)
# L'auteur le fait car tempdir hérite de path qui hérite d'unicode. Or, tous
# les types non-mutables (int, tuple, str, etc, et donc unicode), n'étant pas
# modifiables, ne peuvent être changés dans __init__. Ici __new__ est
# utilisé pour retourner un path tout en créant un dossier temporaire, ce
# qui ne marcherait pas dans __init__. Il est très rare d'avoir besoin de
# s'occuper de __new__.
#</sm>
 
class tempdir(path):
    """
    A temporary directory via tempfile.mkdtemp, and constructed with the
    same parameters that you can use as a context manager.
 
    Example:
 
        with tempdir() as d:
            # do stuff with the path object "d"
 
        # here the directory is deleted automatically
    """
 
    @ClassProperty
    @classmethod
    def _next_class(cls):
        return path
 
    def __new__(cls, *args, **kwargs):
        dirname = tempfile.mkdtemp(*args, **kwargs)
        return super(tempdir, cls).__new__(cls, dirname)
 
    def __init__(self, *args, **kwargs):
        pass
 
    def __enter__(self):
        return self
 
    def __exit__(self, exc_type, exc_value, traceback):
        if not exc_value:
            self.rmtree()

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

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

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

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

flattr this!

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

Prérequis :

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

J’ai plusieurs mamans

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

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

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

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

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

On annule tout.

On recommence.

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

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

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

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

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

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

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

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

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

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

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

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

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

Donc dans notre exemple, si je fais :

class ProtectionOffensive(Arme, Protection):
    pass

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

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

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

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

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

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

Faites attention !

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

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

La composition (POO pour les vrais mecs)

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

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

Retournez à notre exemple de jeu video :

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

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

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

Reprenons notre code des armes, un peu adapté :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

C’est la partouze des objets, quoi.

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

Choisir entre l’héritage et la composition

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

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

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

Le design pattern “stratégie”

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

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

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

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

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

La ligne la plus importante est :

Strategy = strategy or self._strategy[ext]

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

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

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

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

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

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

flattr this!

]]>
http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-5/feed/ 52
Le guide ultime et définitif sur la programmation orientée objet en Python à l’usage des débutants qui sont rassurés par les textes détaillés qui prennent le temps de tout expliquer. Partie 4. http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-4/ http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-4/#comments Sun, 03 Feb 2013 11:04:56 +0000 Sam http://sametmax.com/?p=4395 Un peu de zik, puisque c’est ce qu’on fait maintenant :

Prérequis :

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
<type '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 "<ipython-input-58-8701a4e82b4b>", line 1, in <module>
    '/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
<bound method AveMaria.prier of <__main__.AveMaria object at 0x20618d0>>
>>> p2.prier
<bound method PaterNoster.prier of <__main__.PaterNoster object at 0x2061c90>>
>>> p1.__init__
<bound method AveMaria.__init__ of <__main__.AveMaria object at 0x20618d0>>
>>> p2.__init__
<bound method PaterNoster.__init__ of <__main__.PaterNoster object at 0x2061c90>>

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 "<ipython-input-67-7e7aec1e78c9>", line 21, in <module>
    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.

flattr this!

]]>
http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-4/feed/ 20
Modèles Django et classes abstraites http://sametmax.com/modeles-django-et-classes-abstraites/ http://sametmax.com/modeles-django-et-classes-abstraites/#comments Fri, 01 Feb 2013 12:40:23 +0000 Sam http://sametmax.com/?p=4361 Je suis le génie de la l'ANPE. Enigma, tu m'as trouvé, et tu as le droit à 3 voeux.]]>

Bonjour Sam & Max,

Je suis le génie de la l’ANPE. Enigma, tu m’as trouvé, et tu as le droit à 3 voeux.

J’ai bien aimé votre blog consacré a dynamiser la communauté francophone python et je voudrais vous poser une petite question.
En fait, Quand il s’agit d’écrire un modèle, ce dernier doit hériter de la classe models.Model

par exemple:
class Entry(models.Model):

je me demande pourquoi exactement models.Model ?
et pourquoi ne pas faire l’héritage directement comme ça:
class Entry(Model)


Une explication de la syntaxe d’héritage des modèles Django ? Qu’il en soit ainsi.

On peut faire les deux. C’est une question d’import.

Si tu fais:

from django import models

Tu importes le module models.

Alors si tu veux hériter de la classe Model du module models, tu dois préfixer la classe du module (c’est ce qu’on appelle un namespace) : class Entry(models.Model).

Si par contre tu fais :

from django.models import Model

Tu importes la classe Model. Tu peux donc l’utiliser directement : class Entry(Model)

Le choix entre l’un et l’autre est essentiellement une question de style. En Django, pour les modèles on utilise from django import models car on va généralement également utiliser beaucoup de champs (models.IntegerField, models.BooleanField, etc) et que ça évite de tous les importer.

Aussi, je voudrais savoir qu’est ce qu’une Abstract base class ? ( car je sais que c’est un peu ça mais j’arrive pas à faire le lien )


Je ne peux pas faire tomber amoureux, ressusciter les morts ni faire des classes abstraites en Python. Mais je peux t’expliquer pourquoi. Accordé !

Une Abstract Base Class n’existe pas vraiment en Python. Il y a bien un module abc pour les simuler en utilisant des metaclasses, mais il est peu probable que tu en aies jamais besoin.

Dans d’autres langages, les classes abstraites sont des classes “à trou”. C’est à dire qu’elles ne sont pas complètes. On en hérite pour récupérer une partie de leur comportement, et on écrit le reste.

Imagine une classe Vehicule, qui sert de classe de base à une classe Voiture et une classe Moto :

class Vehicule(object):
 
 
    def __init__(carburant):
 
        self.carburant = carburant

Ceci est une classe abstraite. Elle possède des éléments communs à tous les véhicules, mais ne sait pas rouler. Chaque enfant doit implémenter la méthode rouler() :

class Moto(Vehicule):
 
    def rouler(km):
 
        self.carburant -= km * 3
        print 'Brrrrrrrrrrrrrrrrrr'
 
 
class Voiture(Vehicule):
 
    def rouler(km):
 
        self.carburant -= km * 7
        print 'Vrouuuuuuum'

Une classe abstraite est donc une classe incomplète, utile pour rassembler du code commun aux autres classes, mais qui ne marche pas d’elle même.

Dans d’autres langages, ce concept est formalisé par des mots clés, et des vérifications. Pas en Python : toutes les classes sont égales.

Maintenant le concept des classes abstraites dans Django est une application particulière. Je pense que tu poses la question parce que tu as vu ça :

class Vehicule(models.Model):
 
    class Meta:
 
        abstract = True

Dans ce cas particulier, le principe est le même que plus haut, mais appliqué aux models.

L’ORM de django crée en base de donnée une table par classe qui hérite de models.Model. Ce n’est pas ce que tu veux pour Vehicule : Vehicule ne marche pas par elle même, aucun intérêt de créer une table pour elle.

Ainsi Django le formalise l’aspect “abstrait” avec un attribut. Si l’attribut abstract est sur True, Django ne créera pas de table en base de donnée pour ce modèle, car il sait que c’est une classe abstraite, et qui donc n’est pas destinée à être utilisée directement. Tous les attributs du modèle Vehicule qui correspondent à des champs seront copiés dans les enfants, et seront des champs de leurs tables respectives.

Je vous remercie d’avance, et j’aimerais bien si c’est possible que la réponse soit comme le prochain sujet comme ça tout le monde en profite.


Tes désirs sont des ordres, maître.

(Comme d’hab, personne ne fait le vœu de libérer le génie, hein, bande de connards !)

flattr this!

]]>
http://sametmax.com/modeles-django-et-classes-abstraites/feed/ 16
Le guide ultime et définitif sur la programmation orientée objet en Python à l’usage des débutants qui sont rassurés par les textes détaillés qui prennent le temps de tout expliquer. Partie 3. http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-3/ http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-3/#comments Sun, 27 Jan 2013 06:59:49 +0000 Sam http://sametmax.com/?p=4292 Prérequis :

Nous avons vu les attributs de classe et les propriétés, mais de manière très rudimentaire. Il y a beaucoup de choses à savoir sur la question.

Attribut de classe, la totale

Nous avons vu qu’un attribut de classe était accessible par la classe, sans instance :

>>> class TrueLies:
...
...         attribut_de_classe = 'valeur'
...
>>> print TrueLies.attribut_de_classe
valeur

Mais également par une instance :

>>> print TrueLies().attribut_de_classe
valeur

C’est simple et direct. Il n’y a pas de public static virtuel neoconceptuel à mettre devant comme dans certains langages trop cafféinés.

Ce qu’on a pas vu par contre, c’est ce qui arrive si on modifie la valeur de ces attributs.

Pour faire simple :

  • Si je modifie l’attribut au niveau de l’instance, seule l’instance voit les modifications.
  • Si je modifie l’attribut au niveau de la classe, la classe et toutes les instances crées après ont la nouvelle valeur.
>>> instance = TrueLies()
>>> instance.attribut_de_classe = 'nouvelle valeur'
>>> print instance.attribut_de_classe
nouvelle valeur
>>> print TrueLies.attribut_de_classe # ça ne change rien pour la classe
valeur
>>> TrueLies.attribut_de_classe = 'encore une nouvelle valeur'
>>> print TrueLies.attribut_de_classe
encore une nouvelle valeur
>>> print instance.attribut_de_classe # ça ne change rien pour cette instance
nouvelle valeur
>>> print TrueLies().attribut_de_classe # mais pour une nouvelle oui
encore une nouvelle valeur

Comme self est l’instance en cours, vous pouvez remplacer instance par self dans l’exemple ci-dessus (dans une méthode bien sûr, pas dans le shell), ça marche pareil.

Vu comme ça, ça à l’air d’être super pour donner une valeur par défaut à des attributs.

C’est une mauvaise idée.

En effet, les attributs de classes sont initialisés une seule fois, à la première lecture du code par Python. Pour les objets immutables comme les strings ou les int, on s’en branle. Mais pour les objets mutables comme les dicos ou les listes, c’est la merde.

>>> class TrueLies:
...
...         attribut_de_classe = [] # mettons une liste ici
...
...
>>> flim_pas_sur_le_cyclimse = TrueLies()
>>> etranger_qui_vole_le_travail_des_francais = TrueLies()

On a donc deux instances de TrueLies. A priori, on a aussi deux valeurs de attribut_de_classe, une pour chaque instance ?

Des faux seins sur un FAUX de norman fait des vidéos

Norman va bientôt faire un film avec les robins des bois au fait

>>> id(etranger_qui_vole_le_travail_des_francais.attribut_de_classe)
28992072
>>> id(flim_pas_sur_le_cyclimse.attribut_de_classe)
28992072

Comme vous pouvez le voir c’est le même id. attribut_de_classe est la même chose, car Python initialise attribut_de_classe une seule fois pour toute la session. Les deux instances ont donc un attribut qui contient une référence (puisque TOUT est référence en Python) qui pointe sur la même liste.

Dans les fait, ça veut dire que si on modifie l’un, ben forcément la modification est visible de l’autre côté aussi :

>>> etranger_qui_vole_le_travail_des_francais.attribut_de_classe.append(1)
>>> flim_pas_sur_le_cyclimse.attribut_de_classe
[1]

C’est rarement ce qu’on veut.

Donc ne donnez pas de valeur par défaut dans les attributs de classe. Faites ça avec __init__:

>>> class TrueLies:
...
...         def __init__(self):
...
...                 self.attribut_tres_classe = []
 
>>> flim_pas_sur_le_cyclimse = TrueLies()
>>> etranger_qui_vole_le_travail_des_francais = TrueLies()
>>> flim_pas_sur_le_cyclimse.attribut_tres_classe.append(1)
>>> flim_pas_sur_le_cyclimse.attribut_tres_classe
[1]
>>> etranger_qui_vole_le_travail_des_francais.attribut_tres_classe
[]

Le comportement attendu est le bon ici.

Ok, mais alors ils servent à quoi ces attributs à deux cents, là, cousin ?

- Et ben wesh, tu vois, ils servent à stocker les constantes et le cache.

- Ouais quand j’ai constamment du stock j’ai du cash, man.

- héééééééééééé… xactement.

Donc, d’abord, on met les pseudo constantes en attributs de classe. Je dis pseudo car il n’existe pas de constantes en Python. On parle de constante quand une variable est écrite toute en majuscule, une convention pour dire “le programme ne change jamais la valeur de cette variable (et t’as pas intérêt à la changer, pigé ?)”.

class TrueLies:
 
    NOMBRE_DE_BALLES_DANS_LE_CHARGEUR = 10000

On peut être certain que Schwarzy ne recharge jamais (y a que Thierry Lhermitte qui ferait un truc aussi ringard). Donc le nombre de balles dans le chargeur ne varie pas. On le met comme attribut de classe. C’est essentiellement à titre informatif. Pour nous ça change rien, mais pour quelqu’un qui va utiliser le code, il sait qu’il peut chercher toutes les constantes liées à TrueLies en faisant TrueLies.LES_TRUCS_EN_MAJUSCULES.

C’est l’usage le plus courant.

On peut aussi utiliser les attributs de classes pour créer une API déclarative, comme le fait l’ORM de Django. Mais bon, c’est mega advanced, donc je mets de côté le how to. Le jour où vous coderez un truc comme ça, vous lirez pas un article pour débutant.

Enfin on peut utiliser les attributs de classe pour partager des données entre les instances. Par exemple du cache.

class TrueFalseSomeWhatLiesMaybeWhoKnows :
 
    _cache = {}
 
 
    def calculer_le_nombre_de_balles_a_la_seconde(scene):
 
        # si y a rien dans le cache, on fait le calcul et on le met dans le cache
        if scene not in self._cache :
 
            self._cache[scene] = # mettre un calcul bien compliqué ici
 
        # on retourne le contenu du cache
        return self._cache[scene]
 
>>> TrueFalseSomeWhatLiesMaybeWhoKnows().calculer_le_nombre_de_balles_a_la_seconde(1)
56586586
>>> TrueFalseSomeWhatLiesMaybeWhoKnows().calculer_le_nombre_de_balles_a_la_seconde(1)
56586586

Le premier appel va faire le calcul. Mais pas le second, car le résultat a été stocké dans le dictionnaire qui est au niveau de la classe (et donc chaque nouvelle instance a une référence vers ce dictionnaire) et peut donc être réutilisé.

Vous noterez qu’on a appelé la variable _cache et pas cache. C’est encore une convention. Ça signifie, “cette variable est utilisée en interne, t’as pas à savoir ce qu’elle fait, imagine que c’est privé. Circulez, y a rien à voir.” Les outils de complétion de code masquent ces variables par défaut.

Pour la culture, sachez que nommer ses variables __nom les rend “privées” en Python. Néanmoins cette fonctionnalité est facilement contournable, et très peu appréciée dans la communauté, donc évitez-la.

Et puis il y a les méthodes statiques aussi

On a vu les méthodes de classe, qui sont, comme les attributs de classe, des méthodes qui n’ont pas besoin d’instance pour être appelées :

class ArmeeDesDouzeSinges:
    """
        Ouais c'est un remake d'un film français aussi.
        Ça vous la coupe hein ?
    """
 
    SINGES = 12
 
    @classmethod
    def nombre_de_singes_au_carre(cls):
 
        return cls.SINGES * cls.SINGES
 
 
>>> ArmeeDesDouzeSinges.nombre_de_singes_au_carre()
144

Le premier paramètre n’est pas l’objet en cours mais la classe en cours, et c’est tout ce dont nous avons besoin ici pour accéder à SINGES puisque c’est un attribut de classe.

Cet exemple est issu d’un de mes codes réels de productions, vous pouvez en constater l’intérêt évident dans la vie de tous les jours.

Nan je déconne, moi j’utilise plutôt des dromadaires au quotidien.

Bon, mais sachez plus sérieusement qu’il y a en prime des méthodes de classe, des méthodes statiques. C’est la même chose, mais aucun paramètre n’est passé automatiquement.

class LHommeALaChaussureRouge:
    """
        Oui c'est exactement ce que vous pensez. C'est affligeant.
    """
 
    @staticmethod
    def crie_son_desespoir(): # pas de cls
 
        print "Nooooooooooooooooooooooooooooooooon"
 
 
>>> LHommeALaChaussureRouge.crie_son_desespoir()
Nooooooooooooooooooooooooooooooooon

Alors là on arrive dans la feature anecdotique hein, du genre qu’on sort qu’au repas de Noël. Je la mets au menu juste pour que vous sachiez que ça existe, mais franchement je ne m’en sers presque jamais.

L’usage est le même qu’une méthode de classe, mais pour les trucs qui n’ont pas besoin d’avoir accès à la classe en cours.

Bon.

Bref, c’est juste une fonction préfixée. Avantage : elle est un poil plus rapide que la méthode de classe, et elle est mieux rangée qu’une simple fonction. Mais c’est vraiment tout.

Retour sur les properties

Si vous avez bonne mémoire, vous vous souviendrez qu’une propriété est juste un déguisement qu’on met sur une méthode pour qu’elle ressemble à un attribut :

class LesVisiteursEnAmerique:
    """
        Mais si, mais si...
    """
 
    @property
    def replique(self):
 
        return 'okay'
 
 
>>> film_pourri = LesVisiteursEnAmerique()
>>> film_pourri.replique
'okay'

Mais on peut aller plus loin que la lecture. On peut aussi décorer l’écriture et la suppression !

class LesVisiteursEnAmerique(object): # on rajoute (object) truc ici
 
 
    def __init__(self):
        self._replique = 'okay' # c'est privé, pas touche, y a un underscore
 
 
    @property
    def replique(self):
        print 'get'
        return self._replique
 
 
    @replique.setter # le décorateur a le même nom que la méthode
    def replique(self, value): # value est la valeur à droite du '=' quand on set
        print 'set to {}'.format(value)
        self._replique = value
 
 
    @replique.deleter
    def replique(self):
        print 'delete'
        self._replique = None
 
 
>>> film_pourri = LesVisiteursEnAmerique()
>>> film_pourri.replique
get
'okay'
>>> film_pourri.replique = 'zarma'
set to zarma
>>> film_pourri.replique
get
'zarma'
>>> film_pourri._replique
'zarma'
>>> del film_pourri.replique
delete
>>> film_pourri.replique
get

Et là vous allez me dire :

- c’est quoi ce (object) là haut là qui est apparu magiquement ?
- et à quoi ça sert ? Nom d’un remake hollywodien !

À la première question je dirai, réponse dans la prochaine partie. Sachez juste que s’il y a pas ce (object), le setter et le deleter ne marchent pas.

Pour la seconde, imaginez un truc un peu plus choupi, comme une réplique garantie d’être toujours en majuscule :

class LesVisiteursEnAmerique(object):
 
 
    def __init__(self):
        self._replique = 'OKAY'
 
 
    @property
    def replique(self):
        return self._replique
 
 
    @replique.setter
    def replique(self, value):
        self._replique = value.upper() # PAF ! on majusculise
 
>>> film_TRES_pourri = LesVisiteursEnAmerique()
>>> film_TRES_pourri.replique
'OKAY'
>>> film_TRES_pourri.replique = "D'ac"
>>> film_TRES_pourri.replique
"D'AC"

Et voilà le travail.

On peut donc “intercepter” la récupération, la suppression et la modification d’un attribut facilement. Cela permet d’exposer une belle API à base d’attribut, mais derrière faire des traitements complexes.

Il suffit de transformer un attribut normal en méthode, et de lui coller @property au cul.

C’est pour cette raison qu’on n’a jamais de getter et de setter en Python : on utilise les attributs tels quel, et si le besoin se présente, on en fait des propriétés.

Next stop, héritage, overriding, polymorphisme et autres gros mots que vous pourrez ressortir aux soirées mousses dans les hackerspaces.

flattr this!

]]>
http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-3/feed/ 19
Le guide ultime et définitif sur la programmation orientée objet en Python à l’usage des débutants qui sont rassurés par les textes détaillés qui prennent le temps de tout expliquer. Partie 1. http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-1/ http://sametmax.com/le-guide-ultime-et-definitif-sur-la-programmation-orientee-objet-en-python-a-lusage-des-debutants-qui-sont-rassures-par-les-textes-detailles-qui-prennent-le-temps-de-tout-expliquer-partie-1/#comments Tue, 15 Jan 2013 07:30:56 +0000 Sam http://sametmax.com/?p=4134 Prérequis à ce tuto bien chargé :

  • comprendre parfaitement les mots clés les plus courants (conditions, tests, pass, etc);
  • comprendre parfaitement les fonctions (et donc les paramètres avancées en Python);
  • comprendre la notion de référence;
  • connaitre les structures de données de base (string, int, list, dict, etc).

Intro

Il y a des tas de manières de programmer. Des styles. Des formes que l’on donne au code. On leur donne des noms: programmation procédurale, fonctionnelle, orientée flux, par contrat, etc. C’est ce qu’on appelle des paradigmes, des points de vue sur comment on doit faire le boulot.

En vérité, le point de vue n’est pas déterminant. Vous pouvez faire le même boulot en utilisant n’importe lequel. L’important c’est de coder.

Mais chaque point de vue possède des caractéristiques et des outils différents.

Ce que vous allez voir est ce qu’on appelle la programmation orientée objet, ou POO. C’est un simple point de vue, un outil, mais il est très utilisé en Python, Ruby ou Java.

Quand vous avez appris la programmation, on vous a montré comment stocker des données dans des structures de données:

  • les listes
  • les chaînes
  • les entiers
  • les dictionnaires
  • etc

Et on vous a montré comment créer un comportement pour votre programme en utilisant des mots clés, puis plus tard en utilisant des fonctions pour regrouper ces mots clés.

En Python, à ce stade, vous utilisez des fonctions pour agir sur des structures de données.

La programmation orienté objet, c’est un style de programmation qui permet de regrouper au même endroit le comportement (les fonctions) et les données (les structures) qui sont faites pour aller ensemble.

C’est tout. C’est une simple question d’organisation du programme.

Qu’est-ce qu’un objet

Un objet est un… truc. Un machin. Un bidule.

Ça peut vous paraître une définition floue, mais c’est parce que c’est exactement ce que peut être un objet: n’importe quoi que vous décidiez de coder. L’objet est un moyen de dire à la machine : “ce < entrez_ici_un_nom_de_truc > possède telle donnée, et fait telle chose avec”.

En Python, absolument tout est un objet : une chaîne, un entier, un dictionnaire, une liste, une fonction… Vous avez donc manipulé des objets sans le savoir. Maintenant vous allez créer les vôtres.

Créer des objets se fait en deux étapes: décrire à quoi ressemble votre objet, et demander à l’ordinateur d’utiliser cette description pour le fabriquer.

En Python 2.x, cela donne ceci:

class DescriptionDeLObject:
    pass
>>> object_tout_neuf = DescriptionDeLObject()
>>> print object_tout_neuf
<__main__.DescriptionDeLObject instance at 0x3112440>

La description de l’objet (le plan de construction) est :

class DescriptionDeLObject:
    pass

C’est ce qu’on appelle une classe. La classe est le moyen, en Python, de décrire à quoi va ressembler un objet.

On dit ici:

“Cet objet s’appelle DescriptionDeLObject.”

C’est tout.

Ensuite, on crée l’objet:

>>> object_tout_neuf = DescriptionDeLObject()

DescriptionDeLObject() (notez les parenthèses), est la syntaxe Python pour dire “fabrique un objet à partir de ce plan”. Le nouvel objet va être retourné, et mis dans la variable object_tout_neuf.

La variable object_tout_neuf contient un objet issu de la classe DescriptionDeLObject, on dit qu’il contient une instance de DescriptionDeLObject. C’est pour cela que l’action de créer un objet à partir d’une classe est appelée instanciation.

Python ne sait pas grand chose sur cet objet si ce n’est son nom et son adresse en mémoire. Si on fait print dessus, c’est donc ce qu’il vous donne:

>>> print object_tout_neuf
<__main__.DescriptionDeLObject instance at 0x3112440>

On peut créer autant d’objets que l’on veut à partir d’une classe :

>>> DescriptionDeLObject()
<__main__.DescriptionDeLObject instance at 0x31c1d40>
>>> DescriptionDeLObject()
<__main__.DescriptionDeLObject instance at 0x31d6cf8>
>>> DescriptionDeLObject()
<__main__.DescriptionDeLObject instance at 0x31d6bd8>
>>> DescriptionDeLObject()
<__main__.DescriptionDeLObject instance at 0x31d6c68>

Méthodes

Les méthodes sont des fonctions déclarées à l’intérieur de la classe. Méthode est juste un nom pour dire “cette fonction est dans une classe”.

class DescriptionDeLObject:
 
    def la_methode(objet_en_cours):
 
        print 'Edgar Morin'

Nous avons créé une “fonction” nommée une_methode dans le bloc de la classe. Puisqu’elle est dans ce bloc, cette fonction est ce qu’on appelle une méthode.

Elle n’existe pas en dehors de la classe.

>>> la_methode()
Traceback (most recent call last):
  File "<ipython-input-12-c02691e8aa46>", line 1, in <module>
    la_methode()
NameError: name 'la_methode' is not defined

Mais, elle est attachée à chaque objet. On peut l’utiliser en faisant < variable_contenant_objet >.< nom_de_méthode >. Ainsi, pour appeler une méthode, il nous faut forcément une instance :

>>> objet_tout_neuf = DescriptionDeLObject()
>>> objet_tout_neuf.la_methode()
Edgar Morin

Arrivé à ce stade, vous devez vous demander “quel est ce objet_en_cours” qui est défini comme paramètre de la méthode ?

C’est une spécificité de Python : quand vous appelez une méthode depuis un objet, l’objet est automatiquement passé en premier paramètre par Python. C’est automatique, et invisible.

C’est très facile à comprendre en faisant une méthode qui retourne objet_en_cours pour voir ce qu’il y a dedans :

>>> class DescriptionDeLObject:
...         
...         def une_methode(objet_en_cours):
...         
...                 return objet_en_cours
...     
>>> ze_object = DescriptionDeLObject()
>>> print ze_object 
<__main__.DescriptionDeLObject instance at 0x3429170>
>>> print ze_object.une_methode()
<__main__.DescriptionDeLObject instance at 0x3429170>

Python fait comme si on avait fait :

ze_object.une_methode(ze_object)

objet_en_cours et ze_object contiennent la même chose : l’objet en cours. objet_en_cours est juste le nom que nous avons donné à notre premier argument, mais Python passe toujours automatiquement en premier argument l’objet en cours afin que vous puissiez modifier cet objet à l’intérieur d’une méthode.

On dit donc que objet_en_cours est l’instance courante.

Une méthode doit donc toujours déclarer au moins un paramètre pour accueillir la référence à l’objet en cours, sinon ça plante. Voyez plutôt :

class DescriptionDeLObject:
 
    def methode_sans_objet_en_cours():
 
        print "test"
 
    def methode_avec_objet_en_cours(objet_en_cours):
 
        print "test"
 
>>> ze_object = DescriptionDeLObject()
>>> ze_object.methode_avec_objet_en_cours() 
test
>>> ze_object.methode_sans_objet_en_cours()
Traceback (most recent call last):
  File "<ipython-input-19-90434b7e7bfa>", line 1, in <module>
    ze_object.methode_sans_objet_en_cours()
TypeError: methode_sans_objet_en_cours() takes no arguments (1 given)

Python dit que methode_sans_objet_en_cours est déclarée sans argument mais on lui en a passé un tout de même. Et en effet, Python lui a passé de manière invisible l’objet en cours en tant que premier argument.

En résumé, on déclare une classe avec une méthode ainsi:

class DescriptionDeLObject:
 
    def nom_de_methode(objet_en_cours):
 
        faire quelque chose ici

Et on l’utilise ainsi:

variable = DescriptionDeLObject()
variable.nom_de_methode()

Conventions

En Python, peu de choses sont forcées. La plupart des choses sont des conventions. Mais ce sont des conventions fortes, les gens y tiennent.

Parmi ces conventions, il y a les conventions de nommage, à savoir:

  • on nomme les classes sans espace, avec des majuscules : NomDUneClasse
  • on nomme le reste en minuscule avec des underscores : nom_de_methode, nom_d_attribut, etc

La convention la plus surprenante est celle du premier paramètre des méthodes qui contient l’objet en cours. Son nom n’est pas forcé, contrairement aux autres langages (comme this en Java par exemple), en fait c’est un paramètre tout à faire ordinaire. Néanmoins, la (très très forte) convention est de l’appeler self :

class DescriptionDeLObject:
 
    def nom_de_methode(self):
 
        faire quelque chose ici

Appelez-donc TOUJOURS le premier paramètre de chaque méthode self, et rappelez-vous qu’il contiendra toujours l’instance courante.

Enfin, les concepteurs de Python ont ajouté une convention supplémentaire : les méthodes appelées automatiquement sont appelées __nom_de_methode__ (avec deux underscores de chaque côté).

En effet, il existe un certains nombre de méthodes que vous pouvez écrire, et si vous les nommez d’une certaine façon, elle seront appelées automatiquement quand une condition spéciale (liée au nom), se présente.

Nous verrons cela avec la méthode __init__.

Attributs

Vous avez vu que les méthodes étaient juste des fonctions attachées à un objet. Hé bien les attributs sont juste des variables attachées à un objet.

En fait, techniquement, les méthodes sont aussi des attributs, mais faisons comme si ce n’était pas le cas et séparons :

  • méthodes : fonctions pour objets
  • attributs : variables pour objets

Comme Python est un langage dynamique, on peut ajouter n’importe quel attribut à n’importe quel objet en utilisant la syntaxe < objet >.< nom_attribut > :

>>> print ze_object.un_attribut # l'attribut n'existe pas
Traceback (most recent call last):
  File "<ipython-input-30-b52a599929f9>", line 1, in <module>
    ze_object.un_attribut
AttributeError: DescriptionDeLObject instance has no attribute 'un_attribut'
 
>>> ze_object.un_attribut = "valeur de l'attribut"
>>> print ze_object.un_attribut
valeur de l'attribut

Et c’est là que vous allez voir l’interêt de self :

class DescriptionDeLObject:
 
    def afficher(self):
 
        # self est l'objet en cours, donc on à accès à ses attributs !
        print self.un_attribut
 
    def modifier(self):
 
        # on peut modifier les attributs depuis l'intérieur
        self.un_attribut = "autre valeur"

On peut accéder aux attributs depuis l’intérieur et l’extérieur d’un objet :

>>> ze_object = DescriptionDeLObject() 
>>> ze_object.afficher() # l'attribut n'existe pas encore
Traceback (most recent call last):
  File "<ipython-input-35-c10abd45fc98>", line 1, in <module>
    ze_object.afficher() # l'attribut n'exite pas
  File "<ipython-input-33-3e1eb4d8e5f6>", line 5, in afficher
    print self.un_attribut
AttributeError: DescriptionDeLObject instance has no attribute 'un_attribut'
 
>>> ze_object.un_attribut = "maintenant il existe !"
>>> ze_object.afficher() 
maintenant il existe !
>>> ze_object.modifier() # l'attribut est modifié par la méthode
>>> ze_object.un_attribut 
'autre valeur'

Comme une méthode est juste une fonction attachée à un objet, on peut lui passer des paramètres. Et une méthode a accès à l’objet en cours, elle peut modifier l’objet en cours.

Donc, une méthode peut modifier l’objet en cours en fonction des paramètres passés :

class DescriptionDeLObject:
 
    def afficher(self):
 
        print "La valeur actuelle est %s" % self.un_attribut
 
    def modifier(self, valeur):
 
        self.un_attribut = valeur * 2
 
>>> ze_object = DescriptionDeLObject()
>>> ze_object.un_attribut = 1 # on met un entier en valeur cette fois
>>> ze_object.afficher()
La valeur actuelle est 1
>>> ze_object.modifier(2) # on passe un paramètre 
>>> ze_object.afficher()
La valeur actuelle est 4

Les méthodes servent exactement à cela : retourner les valeurs à l’intérieur de l’objet, ou à les modifier.

Initialisation d’un objet

On souhaite généralement donner un état de départ à tout nouvel objet créé. Par exemple, si vous travaillez sur un jeu vidéo de course de voitures, vous voudrez peut-être créer un objet voiture avec du carburant et une couleur de peinture.

Il serait contre productif de devoir les spécifier à chaque fois. Pour automatiser le travail, Python met à disposition des méthodes appelées automatiquement quand une condition est remplie. Ce sont les méthodes nommées __methode__.

Dans notre cas, on veut que notre objet ait un état de départ, donc on va utiliser la méthode qui est appelée automatiquement après la création de l’objet. C’est la méthode __init__.

Si vous définissez une méthode avec le nom __init__, Python va automatiquement, et de manière invisible, appeler la méthode après avoir créé l’objet :

class DescriptionDeLObject:
 
    def __init__(self):
 
        print "L'objet a été créé !"
        print "La méthode est appelée automatiquement"
 
>>> ze_object = DescriptionDeLObject()
L'objet a été créé !
La méthode est appelée automatiquement

__init__ est une méthode tout à fait ordinaire. Seul le nom est important: comme elle est appelée ainsi, Python la détecte automatiquement et l’appelle au bon moment.

C’est très utile pour fournir un état de départ:

class Voiture:
 
    def __init__(self):
 
        self.carburant = 100
        self.couleur = "noire"
 
>>> v = Voiture()
>>> v.couleur
'noire'
>>> v.carburant
100

Bien entendu, on veut généralement pouvoir changer l’état de départ. Ici encore, Python nous aide: si vous passez des paramètres à l’instanciation, ils sont passés automatiquement à __init__.

Comme __init__ est une méthode ordinaire (et donc une fonction), on peut lui donner des paramètres avec des valeurs par défaut mais accepter une nouvelle valeur si elle est passée :

class Voiture:
 
    def __init__(self, combien_de_carburant=100, quelle_couleur="noire"):
 
        self.carburant = combien_de_carburant
        self.couleur = quelle_couleur
 
 
>>> v1 = Voiture() # sans paramètres, les valeurs par défaut sont utilisées
>>> v1.couleur
'noire'
>>> v1.carburant
100
>>> v2 = Voiture(50, 'rouge et jaune à petit pois') # on change les valeurs
>>> v2.couleur 
'rouge et jaune \xc3\xa0 petit pois'
>>> v1.couleur
'noire'
>>> v3 = Voiture(quelle_couleur="fushia virant sur l'aigue marine")
>>> v3.couleur
"fushia virant sur l'aigue marine"
>>> v3.carburant
100

Les valeurs passées dans Voiture(valeurs, passées), sont automatiquement repassées à __init__(self, valeurs, passées).

En résumé : __init__ est appelée automatiquement après que l’objet soit créé, et on lui passe les paramètres passés à l’instanciation. Comme __init__ est une méthode et a accès à l’instance courante, elle peut ajouter des attributs à l’objet en cours en fonction de ces paramètres. On utilise ça pour créer des objets avec un état de départ par défaut, et permettre une personnalisation de cet état de départ.

J’ai mis des noms différents pour les paramètres d’__init__ et les attributs de l’objet, mais en réalité on leur met souvent le même nom par convention. Donc l’exemple ci-dessus s’écrirait plutôt :

class Voiture:
 
    def __init__(self, carburant=100, couleur="noire"):
 
        self.carburant = carburant
        self.couleur = couleur

carburant et couleur ne sont pas la même chose que self.carburant et self.couleur : les premiers n’existent que dans __init__. Une fois qu’__init__ a fini de s’exécuter, ils disparaissent. Les seconds sont des attributs de l’objet en cours, et sont donc toujours disponibles tant que l’objet existe. Le fait qu’ils portent le même nom ne pose aucun problème car la syntaxe self. les différencie.

Résumé final

La classe, c’est un plan.

L’objet, c’est ce qu’on crée avec le plan.

Une méthode, c’est une fonction déclarée dans une classe (qui est attachée à chaque objet produit, et on lui passe en premier paramètre l’objet en cours).

Un attribut, c’est une variable attachée à un objet.

Une instance d’une classe, c’est l’objet issu d’une classe.

Un spermophile, c’est un animal dont la queue est assez courte et plus ou moins fournie. Il aime être à 4 pattes et mange parfois des glands. Ça n’a rien à voir, mais je me suis dit qu’il fallait faire passer l’info. Ah oui, et la cuniculture, c’est prendre soin d’un lapinou. La levrette, par contre, n’est pas la femelle du lièvre.

Le vocabulaire en informatique, c’est primordial.

La partie 2
, c’est par ici.

flattr this!

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