Aujourd’hui, on nous a demandé la permission, par mail, de réutiliser un de nos schémas pour un article.

C’est très gentil de demander, mais vraiment ne vous embêtez pas avec ça.

Tout le blog, sauf mention spécifique explicite, est sous licence Creative Common Unported. Vous pouvez donc prendre notre contenu et le publier ailleurs, le modifier, et même le vendre. Et vous ne nous devez rien.

La seule obligation, c’est de citer la source : mettez un lien vers le blog à côté de ce que vous réutilisez.

C’est tout.

Donc inutile de nous écrire pour nous piquer un truc. Pillez mes amis, pillez.

En me baladant dans l’arbo de 0bin.net pour retirer un dox qu’on m’avait signalé je suis tombé sur un dossier au nom bizarre :

# ls -l
total 4
4 drwxr-xr-x 7 root root 4096 sept. 24  2014 --

Hum, voilà qui n’est pas pratique à analyser depuis le bash. Et pourquoi j’ai ce dossier-là d’ailleurs ?

Regardons ce qu’il y a dedans :

# python -c "import os; os.rename('--', "strange_dir")"
# ls strange_dir/
3Q  Dk  k5  Oh  -u

Oh, y a un dossier nommé “-u”…

A ce stade-là, j’ai juste supprimé le truc.

Et j’ai réalisé : on crée les dossiers de l’arbo en fonction du nom du paste, qui est une clé générée côté client, et donc fournie par un code JavaScript non trusté.

Du coup l’attaqueur nous a sans doute passé une commande bash comme nom de fichier. J’imagine, espérant qu’on fabriquait le fichier avec une exécution shell. Comme on utilise le module os pour le faire, je pense que ça n’a eu aucun impact.

J’espère :)

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.