Je suis très content d’avoir inspiré d’autres blogs à suivre le principe “du don du mois”.

Mais pour une fois, c’est moi qui vais suivre le mouvement et me laisser inspirer par sciunto et son don pour la quadrature.

Pour ceux qui ne les connaissent pas, cette asso s’engage jusqu’aux couilles dans le processus démocratique, particulièrement dès que ça touche Internet.

Ces lanceurs d’alerte nous tiennent informés, lancent les débats qui comptent, et interviennent auprès des élus avec une persévérance qui tient de l’écureuil de l’âge de glace.

Le tout sans agression, avec intelligence, analyse et respect.

Merci. 50 euros pour cette donation.

Il y a une tendance ces derniers temps à vouloir demander des changements dans Python pour le faire correspondre à une quelconque forme de fantasme qu’a chaque membre de chaque secte qui demande à corps et à cri telles ou telles modifications.

Sans ordre précis :

• la FP c’est la vie. Tout doit être immutable.
• je veux que tout soit asynchrone. Ouai même les boucles for. Au et puis non, filez-moi juste des appels récursifs.
• aucun programme n’est possible sans multi-core. Il me faut du multi-core. Mon problème d’érection vient du fait que mon script de 3 lignes utilise qu’un CPU.
• il faut changer le système d’import pour faire juste “import truc” et rien d’autre.
• les go-routine c’est trop de la balle, réécrivez tout Python pour retirer le GIL, virez asyncio et changez la syntaxe du langage.
• et je veux des lamdbdas multilignes, Dieu m’a dit que c’était bon.
• le typage dynamique est une honte, haskel est un vrai langage, il faut faire pareil.
• mais où est le pattern matching ?

En clair, vous ne voulez pas utiliser Python.

Alors utilisez un autre langage : Lisp, Go, Javascript, whatever, mais ne demandez pas à un chien de miauler.

Le système d’import est là aussi pour faciliter la programmation exploratoire et les scripts courts, pas juste de coder Youtube. La mutabilité permet de simplifier la formation des nouveaux venus. Tout programme n’a pas de problèmes de performances, et ceux qui en ont ne sont pas forcément résolues pas l’asyncio ou le multicore, qui rendent le code plus complexe. Le GIL rend Python rapide sur un core et facile la maintenance pour la toute petite équipe des core dev. Les restrictions syntaxiques ont un but stylistique qui tient de la philosophie du langage basée sur la facilité à lire le code. Le typage dynamique permet la rapidité d’écriture d’un code souple.

Ce sont des fonctionnalités. Pas des accidents. Des choix volontaires, conscients.

Elles se font au détriment d’autres fonctionnalités, et tient compte de l’héritage du passé, car on ne peut pas tout avoir. Peut-être préférez-vous les autres fonctionnalités. Vous avez le droit. Mais dans ce cas utilisez une techno qui a fait le choix de mettre ces dernières en avant, ne demandez pas à un projet qui n’a pas fait les choix que vous voulez de changer.

Est-ce que ça veut dire que Python ne va pas changer ? Qu’il va rester dans son état et ne pas se moderniser ?

Certainement pas !

En fait durant les 3 dernières années Python a énormément changé.

Toutes ces demandes sont entendues, et explorées et quand on y trouve une réponse bénéfique, celle-ci est intégrée au langage. Python 3 a été une réponse. Les types hints ont été une réponse. Asyncio a été une réponse. La 3.6 aura une réponse pour le multi-core.

Mais ces réponses se feront toujours dans le cadre de la philosophie et des contraintes du langage. Inutile d’espérer que Python se transforme en Erlang, Julia ou R, ça n’arrivera pas.

Par ailleurs, vous n’en avez probablement pas besoin. La plupart de ces requêtes sont des demandes de poney car il existe déjà des outils pour traiter ces problématiques. C’est vrai que ça peut être cool un poney, mais ce n’est pas un besoin. La PSF est généreuse en dons équestres, et on en reçoit régulièrement, mais il ne faut pas abuser : utilisez les méthodes qui existent déjà et qui fonctionnent. Ou comprenez que votre façon de faire n’est pas celles de milliers d’utilisateurs de Python qui l’utilisent ainsi parce que cette manière est optimale pour eux.

Apprenez à connaitre le langage plutôt que vouloir le muter pour qu’il comble votre TOC ou votre ignorance.

Parfois, les outils en place ne sont pas suffisants ou sont contraignants. C’est le cas pour le packaging, par exemple. Et dans ce cas, soyez patient, ou participez à la solution, ou encore prenez une autre techno. Toutes ces réponses sont valables. Tapez du pied et pleurer pour un appaloosa ne l’est pas.

Je donne sa chance au produit.

Vraiment.

Régulièrement je retourne vers des technos que j’avais écartées pour voir comment elles ont évolué. Peut-être que c’est mieux. Peut-être que j’ai changé et que maintenant ça me parle.

Mais là, non ! Non, non, non !

Je m’en vais rejeter un coup d’œil vers buildout, un des premiers systèmes de build Python qui résout les problématiques de pip, virtualenv, cookiecutter et bien plus. Un couteau suisse robuste et polyvalent.

Je l’avais mis à la poubelle pour sa difficulté de mise en œuvre et sa doc pourrie. Un produit typiquement dans la philosophie de la communauté Zope dont il est issu : super puissant, super flexible, et aussi plaisant qu’un cactus dans le cul.

Réflexe logique, aller sur la page pypi, et dès le premier paragraphe je lis la description:

Assembly runs the gamut from stitching together libraries to create a running program, to production deployment configuration of applications, and associated systems and tools

Je n’invente rien. Il y a quelqu’un qui a écrit ce texte en ce disant que c’était pertinent. Il a dû être super content de lui le con. Je l’imagine en train de taper sur son clavier, mettant un point final à cette phrase un sourire aux lèvres. Fier. Le sentiment du devoir accompli.

Il avait raison sur un point : avec ce texte on sait tout ce donc on a besoin de savoir sur buildout, c’est-à-dire qu’il ne faut pas l’utiliser.

Au revoir.

P.S: je ne suis pas un demeuré, bien entendu que je suis allé plus loin et que j’ai passé du temps sur le site officiel. Je vous fais ici un résumé de ma pensée.

La période de vaches maigres se termine, et les dons reprennent.

Ce mois-ci, c’est Framasoft, la référence site français en matière de soutien au monde du libre, qui en bénéficie.

J’ai commencé ma carrière avec deux sites : le (feu) site du zéro, aujourd’hui transmuter en l’horrible openclassroom, et framasoft.

Pour ceux qui ne connaissent pas framasoft, ils ont commencé comme un annuaire de logiciels libres, au début surtout pour Windows. Ils permettaient à des petits joueurs de se faire connaitre comme Firebird, l’ancêtre de Firefox, et animaient une communauté super sympa via leur forum. Quand je cherchais une info sur un logiciel, je passais toujours par eux : c’était un gain de temps, et j’avais beaucoup plus confiance en leurs sources que les autres.

Aujourd’hui Framasoft a bien évolué : éditeur de livres, mise en place de nombreux web services et blog d’alerte…

Je ne rends presque plus visite à l’annuaire original, mais j’utilise quelques services comme framapad.

Ce don, c’est surtout pour les nouveaux venus dans le monde du libre, qui auront besoin comme j’en ai eu besoin d’une source d’information fiable. C’est aussi un remerciement, et la reconnaissance de leur ténacité : ils sont là depuis des années malgré les problèmes de trésorerie et la masse de taff incroyable que ça représente.

50 euros pour eux. Et merci.

Depuis que je me suis remis à bosser sur le blog, les coups de main afflux, et c’est très agréable.

Par exemple, on a un mirroir statique du blog sur github pour pouvoir le lire hors ligne. On peut le cloner, mais le plus simple est de télécharger le zip.

Le problème, c’est qu’il faut crawler le blog pour le générer, et je ne l’ai pas fait depuis des mois et des mois, du coup il manquait plein de trucs.

Mais c’est sans compter une petite PR d’un lecteur, qui a tout mis à jour.

Merci pour le poisson !