Rédaction d'une collection de tutoriels Python

Qui ? Quoi ? Comment ?

a marqué ce sujet comme résolu.

Je viens aux nouvelles par rapport à ce que j'écris. Je tourne au ralenti ces temps-ci dessus, comme je l'avais imaginé, j'espère reprendre assez vite. Il ne me reste plus que 3 chapitres à vraiment rédiger, puis ensuite revoir/corriger/reformuler le tout.

+1 -0

@nohar : oui c est vrai. Je peux soit : mettre un lien vers le tuto pyhame d oc, soit en faire une breve intro, ce sera bref mais simple (l intro) :)

Je pense opter pour la deuxième

Folaefolc

Vu la qualité du tutoriel d'OC, j'ose espérer que la première option serait de toute façon refusée à la validation.

+1 -0

La rédaction de la suite de l'article sur les coroutines a bien avancé. Celui-ci est hébérgé sur ce dépôt GH: https://github.com/ArnaudCalmettes/article-async .

Ce texte (peut-être découpable en plusieurs articles) a pour ambition de faire découvrir la programmation asynchrone à des débutants, au travers d'un certain nombre d'étapes très pragmatiques, centrées sur un exemple concret.

J'apprécierais énormément si des débutants pouvaient y jeter un œil et me faire des retours (directement sur GH ou ici) sur la clarté des explications.

+5 -0

Pour les "debutants" : sincèrement n'hésitez pas à poser des questions et faire des remarques. Même si elles vous semblent "bêtes". Son article vise des débutants. Ça aide beaucoup qu'on mette en lumière ce qui ne nous est pas évident quand on a un peu d'expérience. Des choses qui semblent évidentes ne le sont probablement pas pour des débutants.

+1 -0

Je ne suis pas un débutant en programmation, loin s'en faut, en revanche je ne connais rien à Python. Voici mes remarques sur ce qui est disponible pour l'instant (je n'ai pas prêté particulièrement attention à l'orthotypo, mais a visto de nas c'est bon).

Exemple n°1

au moyen de la builtin next()

Pour un débutant, « une built-in » n'est pas forcément un terme connu. « Fonction standard » serait sans doute plus clair.

1
`schedule(loop, task)`

(Et dans la suite du code.) C'est du pinaillage, mais ce n'est pas une boucle, c'est une file, du coup le nom de loop ne me paraît pas le plus adapté.

1
return self.coro.send(self.msg)

Quand je suis tombé sur cette ligne, j'ai bloqué, ne comprenant pas ce qu'elle faisait. Tu l'expliques dans l'exemple suivant, du coup, ce serait bien de prévenir que les explications viendront plus tard.

Exemple n°3

1
while not all(task.is_done() for task in tasks):

Il n'y a pas besoin de crochets pour faire une liste en compréhension en Python ?

Exemple n°4

On se rend compte que les performances de notre serveur de fast-food se dégradent plus ou moins

Il faut 8 secondes pour servir 2 clients, soit 4 secondes en moyenne par client. Il faut 20 secondes pour servir 10 clients, soit 2 secondes en moyenne par client. Pour moi, ses performances se sont accrues. ^^ J'ai bien compris ce que tu voulais dire, mais cela demanderait à être reformulé.

Exemple n°5

voire même

Non. C'est mal.

passe-t'il

passe-t-il

+2 -0

Il n'y a pas besoin de crochets pour faire une liste en compréhension en Python ?

Pour une liste en compréhension oui mais pas pour un générateur. En gros la il crée simplement un itérateur. Tu ne peux pas indexer le résultat (ce n'est pas une liste) mais tu peux itérer dessus (une fois)

+4 -0

Je prends note de tes remarques. Je vais corriger ces passages.

Il faut 8 secondes pour servir 2 clients, soit 4 secondes en moyenne par client. Il faut 20 secondes pour servir 10 clients, soit 2 secondes en moyenne par client. Pour moi, ses performances se sont accrues. ^^ J'ai bien compris ce que tu voulais dire, mais cela demanderait à être reformulé.

Oui, il faudrait que je précise que ce qui importe, c'est le temps d'attente du client, mesuré entre le moment où il a passé sa commande et celui où il la reçoit.

Edit : À propos de l'emploi de loop : c'est précisément le nom donné à la boucle événementielle par asyncio, du coup le choix du nom me semble plutôt adapté… Je vais voir si je ne peux pas trouver mieux.

Edit 2:

OK, la différence est subtile. Ça ressemble tellement à

1
all [is_done task | task <- tasks]

qu'on pourrait faire en Haskell, que j'ai pensé que all() bossait sur une liste en Python aussi.

En fait, la sémantique est strictement la même qu'en Haskell. Simplement, en Python, l'évaluation n'est pas paresseuse par défaut, donc si on veut produire des éléments au fur et à mesure que l'on en a besoin, on va utiliser une expression génératrice plutôt qu'une liste en intention.

On peut également passer une liste (ou n'importe quel objet du moment qu'il est itérable) à cette fonction.

+1 -0

Je suis resté bloqué sur un truc qui m'a surpris :

Dans ce code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
STATUS_NEW = 'NEW'
STATUS_RUNNING = 'RUNNING'
STATUS_FINISHED = 'FINISHED'
STATUS_ERROR = 'ERROR'

class Task:
    def __init__(self, coro):
        self.coro = coro  # Coroutine à exécuter
        self.name = coro.__name__
        self.status = STATUS_NEW  # Statut de la tâche
        self.msg = None  # Message à envoyer à la tâche
        self.return_value = None  # Valeur de retour de la coroutine
        self.error_value = None  # Exception levée par la coroutine

    # Exécute la tâche jusqu'à la prochaine pause
    def run(self):
        try:
            self.status = STATUS_RUNNING
            return self.coro.send(self.msg)
        except StopIteration as err:
            self.status = STATUS_FINISHED
            self.return_value = err.value
        except Exception as err:
            self.status = STATUS_ERROR
            self.error_value = err

        def is_done(self):
            return self.status in {STATUS_FINISHED, STATUS_ERROR}

        def __repr__(self):
            return "<Task '{name}' [{status}] ({res!r})>".format(
                name=self.name,
                status=self.status,
                res=(self.return_value or self.error_value)
            )

Les def inclus dans l'autre, c'est pas normal non ?

+2 -0

Bon, je viens d'entamer le 6e exemple dont l'objectif est d'implémenter une appli réseau. Je pense faire un serveur de chat, parce que c'est complètement adapté à l'asynchrone et en même temps relativement facile.

Je pense m'arrêter à 7 ou 8 exemples. Du coup vu la longueur je crois que ce serait mieux de le publier en deux fois : d'abord les 4 premiers exemples qui tournent autour du concept de programmation asynchrone, puis trois ou quatre autres qui abordent plus spécifiquement asyncio et les applis réseaux (et pourquoi pas certains modules qui fonctionnent avec asyncio, comme aiofile, aiohttp voire aioredis).

Qu'en pensez vous ?

+2 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte