Aller, un petit article de POO un peu avancée pour faire marcher ses neurones ce WE.

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

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

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

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

Ce qui permet à une souclasse de changer la strategy ou non :

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

Ou de changer la strat dynamiquement :

hop = MonObjet()
 
hop.stategie = SuperNewStrat()

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

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

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

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

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

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

truc = MonObjet(UneStrategieDifferente)

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

class MonObjet:
 
    # On appelle souvent cet attribut "strategy_class" ou "strategy_factory"
    strategie_par_default = MaStrategie
 
    def __init__(self, strategie=None):
        self.strategie = strategie(self) if strategie else self.strategie_par_default(self) 
    ...
 
class MonSousObjet(MonObjet):
    # Et boom, overriding de la stratégie par la classe enfant en une ligne.
    # Django fait ça par exemple avec les classes based views et l'attribut 
    # model
    strategie_par_default = MonAutreStrategie

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

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

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

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

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

J’ai déjà donné à Framasoft il y a 2 ans alors que je n’utilisais plus vraiment le site. Plutôt en remerciement de tout ce qu’ils ont fait pendant que j’étais encore sous Windows XP à bricoler avec Phoenix, CloneCD et WinAmp.

Depuis 2001 cet excellent portail a fleuri pour devenir un hébergeur de nombreux services, particulièrement:

• Un traitement de texte et un tableur collaboratifs.
• Un doodle.
• Et surtout un calendrier auquel je viens de m’inscrire.

Pour l’instant je suis très content de l’agenda qui une instance owncloud avec une jolie UI, offrant plusieurs calendriers en parallèle, des partages et exports et tout le tintouin. Donc j’ai thunderbird linké dessus sous Ubuntu, et Solcalendar sous Android (avec pulse sms pour pouvoir taper les sms confortablement sur l’ordi, rien à avoir mais j’en suis content alors je plug).

Bref, cet outil arrive à point pour être bien productif. Reste plus qu’à trouver une alternative à GTG qui est lent comme une grand-mère asthmatique. Si vous avez des suggestions…

Néanmoins, héberger des services comme ça, ça coûte cher. Et framasoft les propose gratuitement.

Donc, don de 30 euros à l’asso. Merci messieurs-dames, vous déchirez.

Pour vous aussi faire un don, c’est par ici.

Mon rêve d’avoir un setup tri-écran, ethernet, casque-micro et chargement avec un seul cable est enfin devenu une réalité.

Et ça a pas été de la tarte.

J’ai un Dell XPS 15 qui a un port USB-C avec thunderbolt. J’ai acheté un dock USB-C caldigit qui propose une entrée micro, une sortie casque, un port HDMI, un display port et un port ethernet, le tout avec un seul branchement via USB-C.

Inutile de dire que ça n’a pas marché. L’USB-C est une vraie jungle, vous connaissez aussi mon avis sur les finitions du XPS 15 et puis la vidéo, ça fait partie de ces trucs qui sont toujours galère en 2017.

Mais…

Après avoir:

• Mis à jour tous les drivers du XPS et flashé le bios et le controller USBC (sic).
• Télécharger le driver ethernet linux de caldigit (sympas !)
• Avoir acheté les bons cables (USB-C respectant le standard, convertisseurs HDMI actifs, etc).
• Flashé le dock avec l’outil caldigit en ayant les bons cables branchés.
• Et bidouillé avec la config d’affichage d’Ubuntu pendant pas mal de temps.

Ca marche.

Pas plug and play pour deux ronds. Mais j’ai enfin un seul cable qui charge l’ordi, m’envoit un débit fibré et étend mon affichage, automatiquement au boot, sous Linux et Windows.

Joie.

Si j’écris l’article, c’est pour dire que:

• C’est possible.
• C’est chiant.
• Le dock caldigit est le seul que j’ai trouvé qui marche avec le XPS (qui suce un max de Watts). Et j’en ai essayé des bidules.
• Les cables et adaptateurs sont le nerf de la guerre. Et ils sont dans le camp ennemie.

Mais surtout pour signaler que le support de caldigit a été fantastique, ce qui est assez rare pour le souligner. Ma premiere interlocutrice via chat a répondu vite et posé les bonnes questions. Identifiant qu’elle ne pouvait pas résoudre le problème, elle m’a redirigé vers le niveau supérieur du support en faisant suivre correctement tout le dossier. Niveau supérieur très technique qui a permi, mail après mail, détail après détail, à faire marche le bouzin. Pas une question à la noix. Pas besoin de me répéter 15 fois. Pas de remise en cause de ma bonne fois ou de prise pour un gogole. Quand les gens font leur boulot ça étonne toujours.

De nombreuses instructions ont été volontairement écartées de Python. Le goto bien entendu, mais aussi le switch, unless et le do...while.

Le but est de limiter le nombre de mots clés à connaitre afin de comprendre le langage. Les créateurs ont choisi donc de mettre de côté des mots clés trop souvent mal utilisés, pas assez utilisés, ou qui possèdent des alternatives suffisantes.

La boucle while est rarement utilisée en Python, en tout cas beaucoup, beaucoup moins que sa petit soeur la boucle for. Avoir besoin d’un do...while est encore plus rare, et donc ne peut faire partie du club très fermé des mots clés réservés.

Si l’on souhaite obtenir l’effet du do..while en python, on fait donc généralement une boucle infinie suivie d’un break sur une condition. Exemple:

import random
 
choix = random.randint(0, 1)
 
while True:
    reponse = int(input('Devinez le nombre: '))
    if reponse < choix:
        print('Plus grand')
    elif reponse > choix:
        print('Plus petit')
    else:
        break
print('Bravo')

Le défaut de cette technique et qu’elle ne rend pas claire dès le début la condition de sortie de la boucle. Aujourd’hui en parcourant la mailling list python-idea, je suis tombé sur un idée pas conne:

import random
 
choix = random.randint(0, 100)
 
while "L'utilisateur n'a pas encore deviné le nombre":
    reponse = int(input('Devinez le nombre: '))
    if reponse < choix:
        print('Plus grand')
    elif reponse > choix:
        print('Plus petit')
    else:
        break
print('Bravo')

Ca marche car les chaînes non vides sont toujours vraie en Python, et ça documente le code :)

L’avantage d’avoir quelques années de programmations dans les pattes et un certain nombres de projets à son actif, c’est qu’on arrive à identifier des motifs communs qui se dégagent encore et encore.

Par exemple, quand j’étais en tout début de carrière, j’ai ouvert l’excellent bouquin “Head first design patterns” et je n’en ai pas retiré grand chose car je n’avais pas la matière pour pouvoir identifier l’utilité des solutions proposées. Bien plus tard, en le relisant, je me suis aperçu que j’avais en fait rencontré moult fois chaque chapitre IRL, base de code après base de code.

La vie apprend les design patterns bien plus efficacement que les écrits. Mais ces derniers ont l’avantage de mettre de l’ordre dans ses idées. Ils mettent des mots sur des pensées floues, et tracent des contours qui délimitent pragmatiquement les concepts.

Aujourd’hui néanmoins, nous n’allons pas parler de design pattern, bien que faire un dossier dessus serait une bonne idée. Mais ça fait des mois que je dois finir le dossier tests unitaires, alors je vais pas commencer un nouveau dossier.

Non, aujourd’hui, nous allons parler d’outils dont on a besoin dans quasiment tous les projets important et qu’on réinvente, ou rapièce, presque à chaque fois.

Dispatching

Que ce soit parce que vous avez un observer, du pub/sub, un système de routing ou des events internes, votre projet finira par avoir besoin d’un système de dispatching. Le dispatching c’est la propagation/distribution de l’information et de son traitement.

Ils ont toujours la même chose en commun:

• Des points centraux qui prennent les entrées et les dirigent vers les bonnes sorties.
• Un système d’enregistrement des points d’entrées (hooks) et des points de sorties (endpoints).
• Une logique de résolution qui permet de faire transiter les données depuis une entrée, vers une ou plusieurs sorties, parfois aller-retour.

Par exemple:

• Le pub/sub de redis ou crossbar.io.
• Le routing URL d’un framework Web comme Django ou Rails.
• Les events d’un UI comme le addEventListener en JS ou connect() en QT.
• La remontée hiérarchique des messages de logs dans le module Python logging.

Ce sont tous des implémentations spécialisées d’un système de dispatching. Le hello world du dispatching est le design pattern observer, qui minimalement ressemble à ça:

>>> class Dispatcher:
...     def __init__(self):
...         self.registry = {}
...     def on(self, event, callback):
...         self.registry.setdefault(event, []).append(callback)
...     def trigger(self, event):
...         for callback in self.registry[event]:
...                 callback()
... 
... hub = Dispatcher()
... 
... hub.on("j'arrive", lambda: print('coucou'))
... hub.on("j'arrive", lambda: print('salut'))
... 
... hub.trigger("j'arrive")
... 
coucou
salut

En fait, à moins de faire uniquement des scripts, vous avez utilisé plein de systèmes de dispatching sans le savoir.

Bien que pour qu’ils soient utiles il faut des versions spécialisées pour chaque usage, c’est un problème générique et il est ridicule que nous devions réimplementer à chaque fois ce truc. Un bon système de dispatching est utile dans tout gros projet. Vous voulez permettre à quelqu’un de lancer du code quand votre système s’initialise ? Créer une logique de plugin ? Bam, il faut du dispatching.

Il faudrait donc un framework en Python qui permette de fabriquer son propre système de dispatching. Il devra bien entendu inclure des implémentations spécialisées au moins pour les cas les plus courants sinon ça fera comme une lib zope et ça prendra la poussière.

Le but étant qu’au bout de quelques années, tout le monde base son implémentation sur cette brique, robuste et documentée, plutôt que de créer son propre système.

En effet, un bon système de dispatching doit pouvoir gérer les cas suivants :

• Mono directionel ou bi-directionel.
• Un ou plusieurs endpoints.
• Middlewares.
• Algo de routing custo.
• Passage de paramètres à l’ajout d’un enpoint.
• Passage de contexte à l’appel de l’endpoint.
• Appel synchrone ou asynchrone des endpoints
• Enpoint locaux ou remotes.
• Gestions de plusieurs dispatchers en parallèle.
• Interconnection de plusieurs dispatchers.
• Adapters pour les dispatchers courants déjà existants.

Le tout bien entendu avec des backends pour chaque partie qu’on puisse swapper.

Configuration

La conf, c’est l’exemple exacte de la fragmentation dans notre métier. C’est l’usine a roues (carrées) réinventées.

Sérieusement, entre le parsing des arguments de la ligne de commande, les fichiers de config, les services de config (etcd anyone ?), les configs sauvegardées en BDD, les API de conf, les variables d’environnement, etc. c’est un bordel sans nom.

Tout le monde a fait son petit fichier params.(ini|yml|xml|json) et ou sa table SQL settings dans un coin. Et la validation. Et la génération. Et les valeurs par défaut. Et l’overriding des envs. Ca change à chaque projet, à chaque framework, à chaque foutu lib.

C’est que le but est simple, mais le problème est complexe. Mais on en a tous besoin, et il n’y a rien, mais alors rien qui existe de générique.

Une bonne lib de conf doit:

• Offrir une API standardisée pour définir les paramètres qu’attend son programme sous la forme d’un schéma de données.
• Permettre de générer depuis ce schéma les outils de parsing de la ligne de commande et des variables d’env.
• Permettre de générer depuis ce schéma des validateurs pour ces schémas.
• Permettre de générer des API pour modifier la conf
• Permettre de générer des UIs pour modifier la conf
• Séparer la notion de configuration du programme des paramètres utilisateurs.
• Pouvoir marquer des settings en lecture seule, ou des permissions sur les settings.
• Notifier le reste du code (ou des services) qu’une valeur à été modifiée. Dispatching, quand tu nous tiens…
• Charger les setting depuis une source compatible (bdd, fichier, api, service, etc).
• Permettre une hierarchie de conf, avec une conf principales, des enfants, des enfants d’enfants, etc. et la récupération de la valeur qui cascade le long de cette hierarchie. Un code doit pouvoir plugger sa conf dans une branche de l’arbre à la volée.
• Fournir un service de settings pour les architectures distribuées.
• Etre quand même utile et facile pour les tous petits scripts.
• Auto documentation des settings.

Pas évident non ? Ça change de “ah bah je vais dumper tout ça dans un settings.py et on verra bien” :)

Les bénéfices d’avoir un bon système de settings sont énormes. D’abord, si il est largement adopté, plus besoin de fouiller dans la doc de chaque projet pour savoir comment l’utiliser. Les problèmes difficiles comme les “live settings” sont réglés une fois pour toute. Plus besoin d’écrire pour la millième fois le code de glue entre son schéma marshmallow + ses params clicks + son parser yml qui sera forcément bricolé. Et une expérience utilisateur bien meilleure avec de la doc, des messages standardisés, des checks de sources de données que d’habitude personne ne fait, etc.

Logging

Oui, je sais, je sais, Python a un excellent module de logging, très riche et polyvalent. Et puis ce ne sont pas les projets de logging qui manquent. Il y a celui de twisted, il y a logbook, logpy… En fait ĵ’ai même pondu devpy.

Malgré ça, force est de constater que tous ces projets sont loin d’être une bonne solution pour convenir à tous.

Le module logging Python manque de configuration par défaut, n’a pas de gestion multiprocessing, aucune facilité pour générer des logs structurés ou binaires, etc. logbook et logpy sont des surcouches qui améliorent, mais sans aller assez loin, l’expérience. Twisted comme d’hab fait le café mais est indigeste. Logpy n’est bien que pour les cas simples.

Un bon module de logging devrait:

• Etre compatible avec la stdlib, et avoir des adaptateurs pour les systèmes les plus courants (comme twisted).
• Gérer le multiproccessing, particulièrement le locking des fichiers ou avoir un process central dédié au log.
• Proposer une UI user friendly de consommation des logs.
• Avoir des pré-configuration prête à l’usage hyper simple et rapide à utiliser pour les cas les plus simples, comme le scripting.
• Gérer des formats avancées: json, binaires, nesting, log structurés, etc. Avec des recettes toutes faites pour les cas courants.
• Avoir une bonne intégration avec les systèmes de logs natifs de l’OS sans besoin de trifouiller.
• Proposer des outils d’analyse de logs.
• Offre des solutions pour les cas simples (console, fichier, coloration, post-mortem, etc) ou complexe mais courants (mail, logstash, sentry, log sur serveur distant, etc).

Au fait, aviez-vous notez que le cœur d’un système de log est un dispatcheur ? :)

Lifecyle

Dès que vous créez un projet, il a un cycle de vie. Il s’initialise, charge les paramètres, load les plugins si il y en a, lance son processus principal, puis finit par s’arrêter, ou foirer, ou les deux.

Si c’est un petit script, ce n’est pas très important, on ne s’en rend même pas compte.

Si c’est un gros projet, vous allez vouloir que le code du reste du monde puisse interagir avec ça. D’ailleurs, tous les gros frameworks vous permettent de réagir au cycle de vie. Django a le fichier appconfig.py par exemple pour lancer du code au démarrage du framework, et des middlewares pour intercepter les requêtes et les réponses. Twisted permet de dire “lance ce code à dès que le reactor est en route”. Pour comprendre Angular ou une app Android, la moitiée du boulot c’est de piger les différentes phases du cycle de chaque composant.

Le cycle de vie est en fait un système de dispatching (surprise !) couplé à une machine à état fini, et concrétisé dans un processus metier. La bonne nouvelle, c’est que des libs de state machines en Python on en a un max, et des bien fournies. La mauvaise, c’est qu’avec la popularité grandissante d’asyncio, on a de plus en plus besoin de gérer explicitement le cycle de vie de ses projets et qu’on a rien de générique pour ça alors la cyclogénèse envahie la communauté.

En effet, dès qu’on a une boucle d’événement comme avec asyncio/twisted/tornado, on a un cycle de vie complexe mais implicite qui se met en place puisque la loop démarre, s’arrête, est supprimée, est remplacée, est en train d’exécuter une tâche, une tâche qui peut générer des erreurs… Et très vite le cycle dégouline de partout, et on commence à coder ici et là pour gérer tout ça sans se rendre compte qu’on créer petit à petit un énième framework de lifecycle. Pas vrai Gordon ?

C’est l’histoire de la viiiiiiiiiiiiiiiie. C’est le cycle éterneleuuuuuuuuuh. De la roue infinieeeeeeee. Codée à la truelleuuuuuuh.

Structure de projet

Bon, imaginons que vous ayez une lib de life cycle, qui charge vos settings avec votre super lib de conf, log tout grâce à votre géniale lib de logging, le tout powered par une lib de dispatching que le monde vous envie. Le perfide.

Je dis “imaginez” parce que dans votre projet vous avez plutôt un tas de crottes retenues par un cornet de glace que vous avez codé pour la enième fois à la va vite en utilisant 30% de libs terce partie, 30% d’outils votre framework du jour et 40% de roux (du NIH sans ame quoi…).

Donc imaginez ça. Et maintenant vous voulez mettre en place un moyen de diviser votre projet en sous parties. Peut être des apps, ou pourquoi pas des plugins. Mais vous voudriez que tout ça soit gérable par un point d’entrée principal, ou individuellement. Que ça se plug dynamiquement. Que ça joue bien avec votre système de conf et de lifecyle. Diantres vous voulez qu’un code externe puisse être découvert et pluggé au système. Choisir si ça tourne dans des threads ou des processus séparés. Mais communiquer entre les partie. Et que tout ça soit découplé bien entendu ! Sauf qu’il y a une gestion de dépendance des plugins…

Pas de problème, vous prenez un bus de communication, un système de plugin, un graph de résolution de dépendances, vos super libs ci-dessus et vous gluez tout ça avec de la logique de chez mémé et de la sueur. Une mémé si ronde qu’elle a un pneu autour de la taille. Et un essieu.

Django a ses apps. jQuery a ses plugins. L’app d’un de mes clients avec un hack a base d’importlib et ctype qui loadait une dll pour charger les drivers de leur matos. Ca roule Maurice, ça roule à mort.

Il nous faut une lib de référence qui permette:

• De diviser son projets en plus petites unités tout en gardant un point central pour faire le lien
• De découvrir, charger et décharger ces unités.
• Permettre de répartir ces unités dans des threads, multiprocess, machines.
• Les faire communiquer.

Et dans les ténèbres les lier

Une fois qu’on a tout ça, il faut bien entendu un gros framework qui permette de faire le lien entre tout ça et coder un projet automatiquement intégré.

Imaginez… Imaginez pouvoir faire un truc comme ça:

from super_framework import projets, config
 
# Tout est configurable et réassemblable, mais le framework offre des réglages 
# auto pour les usages simples
project, app, conf = projets.SimpleProject('name')
 
# Fichier de conf automatiquement créé, parsé et vérifié. Valeurs exposées en 
# CLI et overridables.
@config.source(file="foo.tml")
class Schema(config.Schema):
    foo = config.CharField(max_len=30, live=True)
    bar = config.DateField(optional=True, local=True)
    baz = config.TextField(
        verbose_name="Basile", 
        default="Je sers la science et c'est ma joie"
    )
 
# Lancé automatiquement à la phase d'init du projet
# Des events comme ça sont lancés pour chaque app, et chaque phase de vie de 
# chacune d'elles.
project.on('init')
async def main(context):
    # un log sain automatiquement fourni
    app.log('Debut du projet. Verbosité:', conf.log.level)
 
# Démarre l'event loop. Parse la ligne ligne de commande et les 
# variables d'env, puis le fichier de conf. Mais seulement si le module n'est 
# pas importé (comme __name__ == "__main__")
# Print le fichier de log automatique dès le démarrage du programme
project.cmd()

Et imaginez que de ce petit script, ça scale sur 20 plugins qui peuvent communiquer, un système de settings live, de gestion d’erreurs et de logs aux petits oignons.

Imaginez que l’api bas niveau soit suffisamment flexible pour que les plus grand framework puisse réécrire exactement la même API qu’ils ont déjà en utilisant cette fondation. Imaginez que tous vos projets futures soient du coup compatibles entre eux.

Vous pouvez imaginez longtemps, car ça n’arrivera jamais. Mais j’avais du temps à l’aéroport alors j’ai écris cet article.