Rédaction d'une collection de tutoriels Python

Qui ? Quoi ? Comment ?

a marqué ce sujet comme résolu.

L'autre raison pour laquelle je prefererais ne pas integrer le réseau à la partie portée du livre de Swinnen, c'est que le portage a quand même pour objectif de combler les lacunes du parcours existant, et de le compléter, mais pas de le remplacer. Le projet sur Python sur ce site n'est pas de sortir un cours unique et auto-suffisant mais bien un parcours hypertextuel. Dans ces conditions, prendre aveuglément les mêmes partis-pris pédagogiques que l'auteur d'un livre (la POO par TkInter) serait une erreur évidente.

+1 -0

Pour revenir sur le cours de Gérard Swinnen, j'ai écrit le premier script pour séparer la fichier source (directement converti par pandoc) en de multiples fichiers pour simplifier le travail.

Au niveau des autres tâches encore à réaliser :

  • Supprimer les balises HTML (automatisable au moins en partie) ;
  • Reformater les blocs de code (doivent commencer par ```python, automatisable) ;
  • Replacer correctement les images, ajouter des légendes (manuel).

À propos du cours de Gérard Swinnen, il ne me reste que quelques soucis au niveau des images et je serai en mesure d'importer le contenu dans la semaine.

J'ai relu assez vite le résultat produit, il y a quelques coquilles et problèmes de mise en page qu'il faudra régler manuellement. Mais l'ensemble est plutôt bien.

Je viens de réaliser l'import, qui s'est globalement bien passé. Il reste à faire :

  • Correction de certains sous-titres (des balises de formatage s'y sont glissées) ;
  • Correction des blocs de code (certains sont des lignes successives de code inline plutôt que des gros blocs de code) ;
  • Harmoniser les codes inline (il y a des balises de code et d'autres où c'est du gras qui est utilisé) ;
  • Déplacer ce qui doit l'être en introductions / conclusions ;
  • Et une relecture de chacun des chapitre pour les vérifier au cas par cas.

Ça intéresse des gens que je les ajoute au tutoriel pour me venir en aide ?

Est-ce que je l'ouvre directement en beta pour que tous les intéressés puissent y avoir accès ?

Si tu ouvres la bêta, j'essayerai de jeter un coup d'œil (au moins vite fait, en ce moment, je manque un peu de temps).

En tout cas, merci pour tout ce boulot sur le Swinnen, et plus généralement pour l'animation autour de Python sur ZdS. ;)

+1 -0

Concernant la liste que j'avais énoncée il y a un mois, la plupart des contenus sont restés inchangés (à l'exception du cours sur Tkinter qui a subi une mise à jour courant septembre, et le cours sur la POO envoyé récemment en validation).

Y a-t-il du nouveau quelque part ?

Installer un environnement de développement python avec conda – Envoyé en validation ;

J'ai eu des retours de validation : nécessité de modifications. Je manque encore de temps pour le faire, mais ça devrait très bientôt s'arranger.

Pour numpy, pas de nouveau. J'ai pour but de m'y remettre sous peu.

+0 -0

Qu'en est-il de cet article, qui me semblait bien abouti ?

Vayel

Il faudrait que je le raffraichisse un peu je pense. Il s'arrête à la syntaxe old-school de asyncio (sooooo 2015 !).

À partir de là on a deux choix :

  1. dire que cet article montre juste "comment est foutu asyncio en interne" et se promettre de continuer à l'explorer dans de futurs articles/tuto,
  2. ou bien le modifier pour finir avec des async et des await.

Je penche pour l'approche 1., personnellement, pour plusieurs raisons:

  • L'article est déjà gros,
  • La syntaxe 3.5 "masque" ce phénomène donc on peut l'aborder sans lire cet article.

De plus, j'aimerais bien, pour aborder cette syntaxe, montrer un vrai exemple. Disons un serveur de chat, par exemple. Un tel exemple serait très emprunt de programmation réseau (typiquement on ne se fatiguerait pas à coder des clients au début, on montrerait juste comment ça se passe à coups de netcat dans la console…).

Niveau temps dispo, disons que je bosse actuellement pas mal avec asyncio donc ça a le mérite, même si je n'ai pas énormément de temps, de ne pas représenter un context-switch énorme avec mes occupations actuelles.

Bref, je pense que je vais migrer cet article sur ZdS d'ici la fin de la semaine et le coller en bêta.

+0 -0

Après relecture de mon article sur la programmation asynchrone, je pense en effet qu'il y a plusieurs choses à retravailler dedans pour lui donner une direction. Peu de choses en fait, mais je pense que c'est capital de lui donner plus de contexte pour expliquer les enjeux de la prog asynchrone une bonne fois pour toutes.

Je maintiens une bêta pour ce week-end.

+0 -0

En ce qui concerne les enjeux, un cas d'exemple parlant pour les gens du web c'est la scalabilité des applications web. C'est souvent le cas pratique que je prends pour expliquer l'intérêt des NIO.

Si j'ai bien compris, y'a le même genre de problème en Python. Les gens de bottle l'expliquent ici

J'avais vraiment du mal à comprendre l'intérêt des NIO avant de me retrouver confronté à ce genre de soucis, j'en parle ici (CTRL+F : "sous le capot") si ça peut t'aider.

+1 -0

C'est un peu les raisons que j'explique dans la partie introductive que je viens de rajouter (je suis en train de faire le portage).

Cela dit, j'ai choisi une approche un peu moins liée à la programmation réseau : je veux montrer le modèle de concurrence en lui-même et comment il fonctionne en Python, en gardant les exemples vraiment concrets de la vie réelle pour d'autres articles.

+0 -0

Si j'ai bien compris, y'a le même genre de problème en Python. Les gens de bottle l'expliquent ici

Javier

Le problème de bottle est un peu différent, c'est surtout WSGI qui pose problème. WSGI c'est une "norme" (définit par une PEP) sur comment un serveur web devrait communiquer avec un script python. L'idée est qu'à partir du moment ou un serveur web l'implémente (Apache, nginx, etc.), n'importe quel framework web compatible WSGI (ex Django, Flask, Bottle, etc.) marchera directement dessus. Et c'est une réussite, la majorité des serveurs le supporte. Le soucis est que WSGI date maintenant un peu et n'est pas du tout fait pour faire traiter plusieurs requêtes par un seul thread. Du coup les frameworks web Python sont un peu bloqué pour faire de l'asynchrone.

TL;DR : Ce qu'explique la page, c'est surtout comment contourner les limitations de WSGI.

NB: Je crois qu'il y a un équivalent de WSGI pour l'asynchrone qui est en préparation.

En fait, asyncio permet aussi de se passer purement et simplement d'héberger ton application derrière un serveur web à part : si ton appli est faite avec aiohttp, par exemple, elle peut devenir son propre serveur et passer à l'échelle sans avoir besoin d'un apache. Au pire tu en colles plusieurs instances derrière un nginx qui fait office de load balancer, mais celui-ci n'a vraiment besoin que de transférer la requête HTTP telle quelle, l'appli se débrouille toute seule derrière.

+0 -0

Je lisais ce midi un article sur l'analyse statique des types avec mypy.

Avec la sortie prochaine de Python 3.6 et les type hints sur les variables, je pense que ça ferait un bon sujet à aborder ici. L'outil semble aujourd'hui bien avancé, et l'article tend à démontrer qu'il peut maintenant être utilisé dans des projets de grande envergure.

Ce serait peut-être l'occasion de revenir sur la philosophie qu'adopte Python par rapport au type (duck typing). Suivre le raisonnement suivant par exemple :

  • Python n'est pas typé ? Bien sûr que si !
  • Mais moins que le C, c'est vrai : duck typing
  • Sauf que ça change aujourd'hui : annotations
  • Cas d'application de ces annotations : mypy
+1 -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