Rédaction d'une collection de tutoriels Python

Selon moi la différence c'est là où ils sont rangés. Un article est placé dans la page article où il est alors noyé parmi tous les autres. Encore aujourd'hui, ça pourrait aller, le nombre d'article étant faible. Seulement quand le site commencera a en avoir de plus en plus il va être difficile de retrouver cet article portant sur la lib sqlite parmi 11 pages d'articles. Tant dis qu'un tutoriel est dans sa catégorie qui ne regroupe que des cours portant sur le même sujet.

Il suffit d'une recherche par tags sur les articles, comme ici (peut-être rendre la fonctionnalité plus visible ?).

Pour moi l'intérêt de présenter les modules qui s'y prêtent dans des articles, c'est que ça évite de refaire la doc standard de Python. Ces modules sont déjà extrêmement bien documentés, et si vraiment un type a besoin d'apprendre à se servir de sqlite, la page de référence lui dira tout ce qu'il faut savoir.

En somme, je préférerais qu'on n'écrive pas sur ces modules pour les documenter, mais pour les présenter, avec un simple objectif de veille technique, juste pour dire "regardez ce qu'on peut faire avec ce module, c'est cool, non ?".

• Mauvaise idée d'article: La boucle événementielle de asyncio.
• Bonne idée d'article: Jouons avec asyncio : un serveur de chat en moins de 100 lignes.

Je veux dire :

1
2
3
4
5

>>> "C'est la vie qui dit : "turlututu" et qui s'en va."
File "<stdin>", line 1
"C'est la vie qui dit : "turlututu" et qui s'en va."
                                 ^
SyntaxError: invalid syntax

Je sais, c'est normal si je n'échappe rien. Je crains qu'avec la formule « essayer de le piéger », un lecteur fasse un truc comme au-dessus.

Quand j'ai lu ce paragraphe, je me suis dis : « Ah bon ?, si on mélange tout, python se débrouille tout seul ? C'est gén… Ah non. Il se vautre. ». Quand on me dit d'essayer de piéger quelqu'un, le sous-entendu, c'est que je ne vais pas y arriver. Ou au moins pas tout de suite.

OK, je vois. Je reformulerai cette phrase à l'occasion alors.

Exactement ! Par contre, je me pose aussi la question entre article et tutoriel. Les présenter dans des articles me semblent bien puisque l'objectif, la taille et la fréquence s'y accordent. Cependant, je proposais de les regrouper dans un tutoriel final (ne serait-ce qu'un tutoriel qui renvoie vers les articles) pour leur donner de la visibilité et l'ajouter à la carte. Enfin, je ne sais pas comment vous faites, mais lorsque je cherche un cours, je vais voir dans la section tutoriel -> theme, donc je ne fais pas une recherche générale.

Donc Kje tu serais aussi partant pour rédiger ? Et toi Nohar ?

Pour finir, un autre exemple de module qui peut être sympa à faire découvrir : turtle

Perso je suis partant pour écrire également de courts articles à propos de Python (j'en ai un qui me hante depuis 2 jours à propos des coroutines, et je pense que je vais finir par l'écrire sinon il va m'obséder) ou de la bibliothèque standard. Ensuite, pourquoi pas les inclure dans un gros tutoriel pour les rentabiliser sur le long terme…

En fait je n'ai pas spécialement d'opinion sur le sujet. Je pense que le plus important, c'est de produire du contenu. Une fois que celui-ci existe et a été publié, on pourra toujours le remanier (fusionner des articles en un tutoriel ou autre).

Je suis d'accord avec nohar. Le jour où on aura 5-6 articles lié a le lib standard, on fera un tuto avec. En attendant…

Oui je suis d'accord aussi ! D'ailleurs, j'avais proposé le tutoriel pour une fois que la série serait terminée.

Donc maintenant, il faudrait commencer à définir un prototype de roadmap et mettre en place le début de la série. On le fait dans ce sujet ou l'on ouvre un sujet spécifique histoire de laisser de la lisibilité pour la rédaction des tutoriels ?

En tout cas, rien n'est figé puisque chacun peut apporter ses idées et se porter volontaire pour la rédaction.

Je pense que ça peut être fait ici, le sujet semble fait pour ça. Un sujet peut ensuite être lancé pour un tutoriel particulier s'il est nécessaire d'en parler plus longuement, comme l'a fait nohar.

(j'en ai un qui me hante depuis 2 jours à propos des coroutines, et je pense que je vais finir par l'écrire sinon il va m'obséder)

Bon, j'ai pas pu m'empêcher, il a fallu que je prépare un programme d'exemple pour écrire cet article, voilà un petit pattern sympa qui utilise des coroutines : comment parser un fichier xml de façon incrémentale pour ne traiter que les données qui nous intéressent au moyen d'une machine à états implémentée avec des coroutines.

Ici, une machine à états générique, configurée pour récupérer les titres des derniers articles publiés sur Zeste De Savoir (qu'on peut imaginer compiler automatiquement en lui passant en argument le chemin "item/title") :

 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
36
37
38
39
40
41

#!/usr/bin/env python3
from xml.etree import cElementTree as ElementTree
from urllib.request import urlopen

STATES = {
    'default_state': {
        'transitions': {
            'item': 'item_state',
        },
    },
    'printer': {
        'do_print': True
    },
    'item_state': {
        'transitions': {
            'title': 'printer',
        },
    },
}


def state(tag_name, transitions={}, do_print=False):
    while True:
        event, element = yield
        tag = element.tag
        if event == 'start' and tag in transitions:
            state_name = transitions[tag]
            state_args = STATES[state_name]
            yield from state(tag, **state_args)
        elif (event, tag) == ('end', tag_name):
            if do_print:
                print(element.text)
            return


state_machine = state('root', **STATES['default_state'])
next(state_machine)

rss = urlopen('https://zestedesavoir.com/articles/flux/rss')
for data in ElementTree.iterparse(rss, ('start', 'end')):
    state_machine.send(data)

Oui, sans commentaire c'est imbitable. Mais on peut imaginer ça comme un "grep" pour des xml : la donnée est parsée petit bout par petit bout, et on se déplace dans une state machine au fur et à mesure que le parseur produit des événements. Quand on tombe sur un noeud qui nous intéresse, on en affiche le contenu… On peut imaginer parser des xml gigantesques de cette façon sans jamais saturer la mémoire (et de façon performante !).

@Smokiev : je ne sais pas si une roadmap précise est nécessaire. Si tu as un sujet, propose et rédige le pour avoir des premiers retours.

Pour le moment, voici quelques pistes que j'envisage :

• un article sur turtle
• un article sur webbrowser et un autre module en même temps (pourquoi pas urllib)
• un article sur un module non défini et de parler de pydoc si ce n'est pas déjà fait dans un tutoriel

J'attends de finir mon tutoriel (les deux premières parties sont quasiment terminées) avant de me lancer, mais je pense que ça sera turtle.

J'ai dit que je n'avais pas le temps. Et pourtant hier soir, après une furieuse envie d'écrire, j'ai pondu ça sur le module pyplot de matplotlib.

Je viens de finir de rédiger (relire, corriger, etc.) cet article et de l'envoyer en validation de mon côté.

@nohar : par curiosité, tu utilises minted pour générer la coloration syntaxique de python ?

À vrai dire j'utilise directement pandoc en le laissant se débrouiller tout seul. Je sais pas quel backend il utilise.

Par défaut pandoc utilise kate-hightlight un module haskell qui utilise les fichiers de description de l'éditeur Kate pour faire la coloration.

Plus la Zep 12 approche de sa fin et plus je ressens l' envie, voire le besoin d'écrire un truc sur les class based views de Django.

Si ça rentre dans votre projet je ne rechignerai pas à avoir un co auteur pour éviter la beresina du tuto php datetime.

Quand on ressent le besoin de faire quelque chose c'est fou comme ça va vite. Et en ce moment, je lis beaucoup de truc sur django alors j'espère que tu l'écriras.

Je veux bien aider ! Pas sur que je sois d'une grande aide au niveau de la rédaction mais relecture, corrections je peux faire

Un jour, je ferai peut-être un article sur Sphinx, qui sait…

Cool article, je viens de le lire. Chapeau !