On va se faire une petit intro. C’est un sujet vraiment avancé, donc si vous avez autre chose de moins compliqué à comprendre en Python (n’importe quoi à part les métaclasses :)), ne vous prenez pas la tête sur cet article. Ecoutez juste la musique :

D’abord, rappel sur le fonctionnement des générateurs (qui sont un prérequis de l’article, donc si besoin, relisez le tuto dédié) :

def soleil():
    print('Premier next()')
    print('Yield 1')
    yield 1

    print('Deuxième next()')
    print('Yield 2')
    yield 2

    print('Troisième next()')
    print('Yield 3')
    yield 3

    # pas de quatrième next(),
    # donc on ne passe jamais ici
    print('Pas vu')

# rappel, ceci ne déclenche pas le code 
# de soleil() puisqu'il y a yield dedans
print("Creation du generateur")
undeuxtrois = soleil()

# On execute le code jusqu'au yield 1
res = next(undeuxtrois)
print('res = %s' % res)

# On execute le code jusqu'au yield 2
res = next(undeuxtrois)
print('res = %s' % res)

# On execute le code jusqu'au yield 3
res = next(undeuxtrois)
print('res = %s' % res)
print('Good bye')

## Premier next()
## Yield 1
## res = 1
## Deuxième next()
## Yield 2
## res = 2
## Troisième next()
## Yield 3
## res = 3
## Good bye

Chaque fois qu’on appelle next() sur le générateur, il va exécuter le code jusqu’au prochain yield, et retourner la valeur de celui-ci, puis mettre le générateur en pause.

On peut assigner le résultat d’un yield, mais si on fait des next(), on obtient toujours None :

def lune():

    print('Premier next()')
    print('Yield 1')
    x = (yield 1)

    print('Deuxième next()')
    print('Avant le yield 2, x = %s' % x)
    print('Yield 2')
    x = (yield 2)

    print('Troisième next()')
    print('Avant le yield 3, x = %s' % x)
    print('Yield 3')
    x = (yield 3)

    print('Pas vu')


print("Creation du generateur")
generateur = lune()

res = next(generateur)
print('res = %s' % res)

res = next(generateur)
print('res = %s' % res)

res = next(generateur)
print('res = %s' % res)
print('Good bye')

## Creation du generateur
## Premier next()
## Yield 1
## res = 1
## Deuxième next()
## Avant le yield 2, x = None
## Yield 2
## res = 2
## Troisième next()
## Avant le yield 3, x = None
## Yield 3
## res = 3
## Good bye

La raison est que cette valeur doit venir de l’extérieur. Pour la fournir, il faut utiliser la méthode send() et non la fonction next().

Mais elle ne fonctionne pas du tout pareil. En fait, si on l’appelle cash pistache, ça plante :

print("Creation du generateur")
generateur = lune()
res = generateur.send("A")
print('res = %s' % res)

## Creation du generateur
## Traceback (most recent call last):
## File "test.py", line 24, in 
##   res = generateur.send("A")
##     TypeError: can't send non-None value to a just-started generator

C’est parce que, contrairement à next() qui va jusqu’au prochain yield, send() PART du dernier yield atteint pour aller au suivant.

Il faut donc d’abord arriver à un premier yield avant de faire un send(). On peut le faire en utilisant au moins un next().

Voici donc notre nouveau code :

def lune():

    print('On fait au moins un next()')
    print('Yield 1')
    
    x = (yield 1)

    print('Premier send(), x = %s' % x)
    print('Yield 2')

    x = (yield 2)

    print('Deuxième send(), x = %s' % x)
    print('Yield 3')

    x = (yield 3)

    # Comme on fait un next() et 3 send()
    # on arrive là
    print('Troisième send(), x = %s' % x)
    print('YOLOOOOO')


print("Creation du generateur")
generateur = lune()

next(generateur) # Ou generateur.send(None)

res = generateur.send("A")
print('res = %s' % res)

res = generateur.send("B")
print('res = %s' % res)

res = generateur.send("C")
print('res = %s' % res)
print('Good bye')

## Creation du generateur
## On fait au moins un next()
## Yield 1
## Premier send(), x = A
## Yield 2
## res = 2
## Deuxième send(), x = B
## Yield 3
## res = 3
## Troisième send(), x = C
## YOLOOOOO
## Traceback (most recent call last):
##   File "test.py", line 33, in 
##     res = generateur.send("C")
## StopIteration

send() agit donc comme next(). Il va aller jusqu’au prochain yield et lui faire retourner sa valeur. Mais il y a des différences :

• Elle doit partir d’un précédent yield.
• Donc il faut au moins avoir atteint un yield via next().
• Ce précédent yield peut retourner une valeur : celle passée via send(val).

La valeur peut être n’importe quel objet : string, int, classe, list, etc.

Bref, send() permet de créer un générateur donc le comportement n’est pas figé dans le marbre.

Par exemple :

def creer_fontaine():
    contenu = "soda" 
    while True:
        x = yield contenu
        if x:
            contenu = x


fontaine = creer_fontaine()

for x in range(5):
    print(next(fontaine))

# on change le contenu de la fontaine
fontaine.send("lait")

for x in range(5):
    print(next(fontaine))

soda
soda
soda
soda
soda
lait
lait
lait
lait
lait

On peut même s’en servir pour faire des trucs chelou comme injecter une dépendance à la volée ou contrôler le flux de son générateur :

def fuckitjaiplusdenomcool(start, inc=lambda x: x + 1):
    x = start
    # on controle le flux du générateur en changeant
    # la valeur de x qui peut tout stopper
    while x:
        sent = yield x
        if sent:
            inc = sent
        # la valeur de x dépend de ce bout de code
        # qui est injectable
        x = inc(x)


generateur = fuckitjaiplusdenomcool(1)

for x in generateur:
    print(x)
    if x > 10:
        # si on dépasse 10, on décrémente
        generateur.send(lambda x: x - 1)

## 1
## 2
## 3
## 4
## 5
## 6
## 7
## 8
## 9
## 10
## 11
## 9
## 8
## 7
## 6
## 5
## 4
## 3
## 2
## 1

Mais bon, pas la peine de rentrer dans des cas si compliqués.

Néanmoins, un cas d’usage de send() est de créer une coroutine. Une coroutine est simplement une tâche.

C’est un bout de code qui fait une tache, avec un bout d’initialisation, et un bout de finalisation, et un bout d’exécution.

Par exemple, j’ai un filtre qui prend un fichier rempli d’adresses IP. Il va recevoir du texte, et si le texte contient une adresse IP, il le signale, et remplit un compteur sur le disque.

Si on devait coder ça en objet on dirait :

import re

class Filtre:

    # initialisation
    def __init__(self, ipfile, counterfile):

        with open(ipfile, 'r') as f:
            self.banned_ips = set(f)
        with open(counterfile) as f:
            self.count = int(f.read())
        self.counterfile = open(counterfile, 'w')

    def check(self, line):
        # récupère les ip et check celles qui sont 
        # à filtrer
        ips = re.findall( r'[0-9]+(?:\.[0-9]+){3}', line)
        bad_ips = [ip for ip in ips if ip in self.banned_ips]

        # si il y a des ip à filtrer, on incrémente le compteur
        if bad_ips:
            self.count += len(bad_ips)
            self.counterfile.seek(0)
            self.counterfile.write(str(self.count))

        # on retourn les valeurs trouvées
        return bad_ips

    def close(self):
        self.counterfile.close()

On l’utiliserait comme ça :

f = Filtre("/chemin/vers/liste", "/chemin/vers/counteur")
for line in text:
    print(f.check(line))
f.close()

Notez que pour une tâche, l’API est toujours la même : initialiser, exécuter la tâche autant de fois que nécessaire, puis finaliser.

Les coroutines sont un mot qu’on met sur ce principe (initialiser, exec, finaliser), mais avec une API sous forme de générateur. Le même code en coroutine :

def filtre(ipfile, counterfile):

    # Initialisation
    with open(ipfile, 'r') as f:
        banned_ips = set(f)
    with open(counterfile) as f:
        count = int(f.read())
    counterfile = open(counterfile, 'w')

    # Exécution
    bad_ips = []
    while True:

        try:
            # entree et sortie de notre send(), qui équivaut
            # aux params de "check()"
            line = yield bad_ips

        # GeneratorExit est levé is on fait generator.close()
        # On ne peut pas ignorer cette erreur, mais
        # on peut mettre du code de finalisation ici.
        # Bon en vrai faudrait faire un finally quelque part
        # mais c'est pour l'exemple bande de peer reviewers
        except GeneratorExit:
                counterfile.close()

        ips = re.findall( r'[0-9]+(?:\.[0-9]+){3}', line)
        bad_ips = [ip for ip in ips if ip in banned_ips]

        # si il y a des ip à filtrer, on incrémente le compteur
        if bad_ips:
            count += len(bad_ips)
            counterfile.seek(0)
            counterfile.write(str(count))

On l’utiliserait comme ça :

f = filtre("/chemin/vers/liste", "/chemin/vers/counteur")
next(f)
for line in text:
    print(f.send(line))
# ceci raise GeneratorExit
f.close()

Généralement on veut pas se faire chier à appeler next() à chaque fois, donc toutes les libs à base de coroutine ont ce genre de décorateur :

def coroutine(func):
    def wrapper(*arg, **kwargs):
        generator = func(*arg, **kwargs)
        next(generator)
        return generator
    return wrapper

Afin de pouvoir faire ça :

@coroutine
def filtre(ipfile, counterfile):
    ...

Ca a un double usage : ça appelle next() automatiquement, et ça signale que la fonction est destinée à être utilisée comme coroutine.

Mais voilà, c’est tout, une coroutine c’est juste ça : utiliser un générateur pour faire une tâche qui consiste à s’initialiser, faire un traitement plusieurs fois, et optionellement, se finaliser. On utilisera une coroutine pour ne pas reinventer la roue car c’est un problème bien défini, qui a une solution. D’autant qu’une coroutine bouffe moins de ressources qu’une classe.

Les usages avancés des coroutines impliquent de chaîner plusieurs coroutines, comme des tuyaux.

Souvenez-vous, en Python il est courant de chaîner des générateurs :

def mettre_au_carre(iterable):
    for x in iterable:
        yield x * x

def filtrer_les_pairs(iterable):
    for x in iterable:
        if x % 2 == 0:
            yield x

def strigifier(iterable):
    for x in iterable:
        yield str(x)

# on pipe les données d'un générateur à l'autre
nombres = range(10)
carres = mettre_au_carre(nombres)
carres_pairs = filtrer_les_pairs(carres)
fete_du_string = strigifier(carres_pairs)

for x in fete_du_string:
    print(repr(x))

## '0'
## '4'
## '16'
## '36'
## '64'

On peut faire pareil avec les coroutines. Cependant, la logique est inversée : au lieu de lire les données, on les envoie :

@coroutine
def mettre_au_carre(ouput):
    while True:
        x = (yield)
        ouput.send(x * x)

@coroutine
def filtrer_les_paires(ouput):
    while True:
        x = (yield)
        if x % 2 == 0:
            ouput.send(x)

@coroutine
def strigifier(ouput):
    while True:
        x = (yield)
        ouput.send(str(x))

@coroutine
def afficher():
    while True:
        x = (yield)
        print(x)

nombres = range(10)

# chaque coroutine est la sortie d'une autre
afficheur = afficher()
fete_du_string = strigifier(afficheur)
paires = filtrer_les_paires(fete_du_string)
carre = mettre_au_carre(paires)

# on envoit les données vers la première coroutine
# et elle fait suivre aux autres
for x in nombres:
    carre.send(x)

## '0'
## '4'
## '16'
## '36'
## '64'

Vous allez me dire : “ça fait la même chose, et c’est plus compliqué, quel interêt ?”.

En fait, ça ne fait pas exactement la même chose.

Dans le cas des générateurs ordinaires, on déclenche le traitement par la fin. On fait une boucle qui demande quelle est la prochaine donnée, et si il y en a une, on l’affiche. C’est pratique si on sait qu’on a des données sous la main car on demande (next() est appelée par la boucle for) la donnée suivante à chaque fois : c’est du PULL.

Mais que se passe-t-il si on n’a pas encore les données ? Si on traite des données qui arrivent par évenement ?

Par exemple, si on écrit un serveur HTTP qui doit réagir aux requêtes ?

Dans ce cas, on ne peut envoyer (send()) la donnée suivante dans notre pipeline de générateurs uniquement quand elle arrive, et les coroutines font exactement cela : c’est du PUSH.

En résumé :

• yield permet de faire des générateurs
• On peut demander la prochaine valeur du générateur avec next(). Dans ce cas, le code s’exécute jusqu’au prochain yield.
• On peut envoyer une valeur au générateur avec send(). Dans ce cas, on DOIT partir d’un yield existant duquel on récupère la valeur envoyée via une assignation. Donc il faut au moins un next() avant d’utiliser un send() et un signe égal sur le yield.
• send() va aussi aller au prochain yield et retourner sa valeur.
• Une coroutine n’est qu’une formalisation de la manière d’éffectuer une tâche avec un init, une exécution et une finalisation optionelle en utilisant un générateur. C’est une solution générique à un problème courant, mais plus léger qu’une classe.
• Généralement on décore les générateurs coroutines avec un décorateur @coroutine pour s’éviter d’appeler next() à la main et notifier l’usage qu’il est fait de ce générateur.
• On peut chaîner des coroutines comme on chaîne des générateurs, mais au lieu de lire les données une à une (PULL), on les envoie une par une (PUSH). Cela est pratique quand on ne sait pas à l’avance quand une nouvelle donnée va arriver.

Si vous êtes arrivé jusqu’ici, vous méritez un cookie.

Ca tombe bien, ce blog utilise des cookies, et la loi m’oblige à vous le notifier.

Dictionary views

Quand on voulait travailler sur les valeurs d’un dictionnaire en Python, on avait deux choix:

• faire dict.values() et récupérer une liste entière. Créant une liste entière en mémoire.
• faire dict.itervalues(), et récupérer un générateur. Mais qui ne peut être lu qu’une fois.

Les vues sont une solution intermédiaire: ce sont des objets qui prennent peu de mémoire, mais qui peuvent être lus plusieurs fois.

Exemple:

>>> scores = {'foo': 1, 'bar': 0}
>>> val = scores.viewvalues()
>>> print val
dict_values([1, 0])
>>> 1 in val
True
>>> [x * 2 for x in val]
[2, 0]

Contrairement à une liste, les vues issues d’un dictionnaire ne supportent pas le slicing ou l’assignation et il n’y a aucune garantie d’ordre des éléments. De plus, elles ne peuvent être modifiées.

Bref, une vue ne contient rien, c’est juste un objet qui, quand on accède à son contenu, va le chercher dans le dictionnaire et vous le retourne. C’est ce qu’on appelle un objet proxy: il vous donne l’illusion d’accéder directement aux données pour vous faciliter la vie, généralement en vous les présentant sous une forme différente: ici un itérable.

On peut récupérer des vues pour les valeurs, mais également pour les clés et les couples clés / valeurs. Ces deux types de vues se comportent en plus comme des sets:

>>> scores.viewitems()
dict_items([('foo', 1), ('bar', 0)])
>>> scores.viewkeys() | [3,]
set([3, 'foo', 'bar'])

Puisqu’il est rare d’avoir besoin d’une vraie liste, et comme les vues sont une très bonne alternative aux générateurs, dict.values et consorts retournent des vues en Python 3.

Maintenant vous allez me dire “Mais si les vues sont une si bonne alternative aux générateurs, pourquoi on ne remplace pas tous les générateurs par des vues ?”.

Tout simplement parce que ce n’est pas possible. Un générateur est un mécanisme standard qui permet de produire des valeurs une par une. N’importe qui peut créer un générateur, car c’est un concept portable d’un problème à un autre. On peut l’appliquer à de nombreuses choses: algorithme, flux de données, fichier, etc.

Une vue n’est qu’un proxy qui permet de voir une structure de données sous une autre forme. Il faut coder une vue par type de structure de données, car la vue va chercher les données dans cette structure quand on lui demande. Le code est donc différent à chaque fois.

Python ne permet pas de créer soi-même des vues, mais créer un proxy, c’est à dire un objet qui retourne les valeurs d’un autre objet quand on l’interroge, peut se faire à la main dans tout langage de programmation. Ainsi vous pourriez créer un proxy qui ressemble a une vue des clés d’un dico très simplement:

class keyview(object):

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

    def __iter__(self):
        return self.d.iterkeys()

>>> view = keyview(scores)
>>> for x in view:
...     print x
...     
foo
bar
>>> list(view)
['foo', 'bar']
>>> 

L’implémentation réelle de Python (en C…) ne fait pas vraiment grand chose de plus, juste un travail d’optimisation pour être plus rapide.

memoryview

Les memory views suivent le même principe, mais appliqué à toute structure de données qui supporte le buffer protocole (un certain nombre de méthodes avec un nom et un comportement défini par ce protocole) comme celles trouvées dans le module struct ou array. La structure de données la plus connue qui suit le buffer protocole est la chaîne de caractères.

>>> s = 'Sam & Max eat the road with a Github fork'
>>> ms = memoryview(s)
>>> ms[-1]
'k'
>>> ms[:9]

>>> ''.join(ms[:9])
'Sam & Max'

Le principal intérêt de la memory view appliquée aux strings, c’est que tout slicing retourne une nouvelle memory view. On peut donc travailler sur des parties de la chaînes sans créer une nouvelle chaîne en mémoire.

En revanche, les chaînes unicodes ne sont pas supportées. Il vous faudra jouer avec encode() et decode().