La débâcle de async en 3.7


Quand les nouveaux mots clés async et await ont été introduits en Python 3.5, tout le monde a trouvé l’idée formidable. D’ailleurs, ça a été intégré à JavaScript.

Malheureusement, introduire des mots clés dans un langage est une opération très délicate.

Limites et contournements des mots clés

En Python les mots clés ont une caractéristique importante : on ne peut pas les utiliser pour quoi que ce soit d’autre.

Par exemple, class est un mot clé, donc je ne peux pas créer une variable, un attribut, ou une fonction appelé class. Ceci lève une erreur:

>>> class = 1
  File "<stdin>", line 1
    class = 1
          ^
SyntaxError: invalid syntax
>>> class Foo: pass
... 
>>> Foo.class = 1
  File "<stdin>", line 1
    Foo.class = 1
            ^
SyntaxError: invalid syntax
>>>

Pour cette raison, quand on veut qu’une variable contienne une classe en Python, on la nomme cls:

>>> class Bar:
...     @classmethod
...     def wololo(cls):
...         print(cls, 'wololo')
... 
>>> 
>>> Bar.wololo()
<class '__main__.Bar'> wololo
>>>

C’est aussi pour cela que vous voyez parfois des variables nommées truc_. Souvent from_ par exemple, parce que from est un mot clé.

(pro tip: plutôt que from et to, utilisez src et dest)

Quand en Python 2 on a introduit True et False, un gros problème s’ensuivit: soit on en faisait des mots clés, et on pétait tout le code précédent qui utilisait ces mots, soit on en faisait des variables globales.

Le choix a été de garder la stabilité jusqu’à la prochaine version majeure, et c’est pour cela que:

  • On peut faire True = False en Python 2. Ouch.
  • Python 3 casse ce comportement, et donc ça fait une chose de plus à laquelle il faut penser quand on migre.

Pour la 3.5, on avait donc ce même problème, avec une cerise sur le gâteau: la lib standard utilisait elle-même la fonction asyncio.async.

Le choix a donc de faire de async / await des variables globales, et de les transformer en mot clé en 3.7.

En 3.6, un warning a été ajouté pour rappeler aux gens de migrer leur code.

C’est un sacré taf, et ça comporte des risques comme nous allons le voir plus loin. C’est pour cette raison que l’ajout d’un mot clé dans Python est une des choses les plus difficiles à faire passer sur la mailling list python-idea.

Arrive la 3.7

La 3.7 est sortie avec tout un tas de goodies. Youpi. Mais aussi avec le passage de async/await de variables globales à mots clés, cassant la compatibilité ascendante. Quelque chose de rare en Python, et que personnellement j’aurais réservé pour Python 4, ne serait-ce que pour respecter semver.

Le résultat, tout un tas de systèmes ont pété: des linux en rolling release, des gens qui ont fait l’update de Python à la main, des gens qui maintiennent des libs compatibles 3.5 a 3.7…

D’autant que la 3.5 a asyncio.async, mais 3.7 considère ça une erreur.

Petit exemple avec l’impact sur debian.

Comment on aurait pu éviter ce merdier ?

D’abord, il aurait fallu ne pas introduire asyncio à l’arrache. Dans mon “au revoir” à Guido, je disais que je trouvais que les dernières fonctionnalités majeures de Python avaient été mises en oeuvre de manière précipitée.

Cela se vérifie encore et encore avec asyncio, dont il faudra que je fasse un article pour dire tout ce qui a mal tourné.

Casser la compatibilité ascendante dans une version mineure n’est pas acceptable, même si les dégâts sont limités et qu’on y survivra très bien.

Le fait qu’asyncio soit une API marquée comme “provisional” n’a jamais empêché quelqu’un d’appeler ses variables async. Après tout on utilise les threads depuis bien longtemps.

L’autre problème vient de l’amateurisme qui se glisse de plus en plus dans le dev.

C’est une bonne chose, parce que ça veut dire que la programmation est de plus en plus accessible et accueille de plus en plus de monde.

Mais cela veut dire aussi qu’une grosse part la population de programmeurs est aujourd’hui constituée de personnes qui n’ont ni les connaissances, compétences ou ressources pour faire les choses correctement.

On le voit particulièrement dans le monde JavaScript, ou c’est l’explosion (là encore, ça mérite un nouvel article). Mais l’exemple de la 3.7 nous montre que la communauté Python n’est pas immunisée, et je pense que le problème va s’amplifier.

Que veux-je dire par là ?

Et bien il y a 30 ans, cela ne serait pas venu à l’esprit de la plupart des devs de compiler quelques choses sans mettre les flags en mode parano pour voir ce qui allait péter. Après tout, quand on code en C, on sait que tout peut imploser à tout moment, alors la prudence est une question de culture.

Aujourd’hui par contre, la majorité des devs des langages haut niveau écrivent du code, font quelques tests à la main, et publient ça. D’autres les utilisent. Font des mises à jour en masse. Aucun ne prennent le temps ne serait-ce que d’activer les warnings les plus basiques.

Comme tout est facile à première vue, et c’est quelque chose dont on fait la promotion pédagogiquement parlant, car ça incite les gens à se lancer, on oublie la complexité inhérente à la programmation.

Mais il y a une différence colossale entre avoir un code qui marche une fois sur sa machine, et un code prêt pour la production.

Par exemple en Python, vous pouvez demander l’activation des warning pour chaque appel avec:

python -Wd

En 3.6, ça implique ceci:

>>> def async():
...     pass
... 
<stdin>:1: DeprecationWarning: 'async' and 'await' will become reserved keywords in Python 3.7

L’info a toujours été là. Prête à être utilisée.

Mais alors pourquoi ne pas afficher tous les warnings, tout le temps ?

Et bien si je le fais:

python -Wa

Voilà ce que ça donne quand je lance juste le shell de python 3.6:

Voir le code sur 0bin.

Vous comprenez donc bien que ce n’est PAS activé par défaut. En fait, originalement le message était dans le corps de l’article, mais j’ai du le mettre sur 0bin parce que ça faisait planter WordPress. Si.

A chaque upgrade, il est important de vérifier les warnings pour préparer ses migrations futures.

Oui, c’est du boulot.

En fait…

La programmation, c’est BEAUCOUP de boulot

Même si on arrive maintenant à extraire une frame vidéo en gif en une ligne de commande.

Surtout maintenant qu’on y arrive en fait, car on multiplie les agencements hétérogènes de boites noires pour créer nos merveilleux programmes qui font le café.

Alors on prend des raccourcis.

Et puis aussi, parce qu’on ne sait pas. Qui parmi les lecteurs du blog, pourtant du coup appartenant à la toute petite bulle des gens très intéressés par la technique, connaissaient le rôle des warnings et comment les activer ?

Mais ce n’est pas le seul problème. Il y a clairement une question d’attentes et de moyen.

L’utilisateur (ou le client) final veut toujours plus, pour moins cher, et plus vite !

Et le programmeur veut se faire chier le moins possible.

Comme la complexité des empilements d’abstractions augmente, cela conduit à ignorer ce sur quoi on se base pour créer ce qui doit combler notre satisfaction immédiate.

J’ai parlé d’amateurs plus haut.

Mais je ne parle pas simplement de mes élèves. De mes lecteurs.

Je parle aussi de moi.

Prenez 0bin par exemple.

Il n’est plus à jour. Il n’a pas de tests unitaires. Il a des bugs ouverts depuis des années.

Ce n’est pas pro du tout.

Sauf que je ne suis pas payé pour m’en occuper, et c’est bien une partie du problème: nous sommes de nombreux bénévoles à faire tourner la machine a produire du logiciel aujourd’hui. Donc si je n’ai pas envie, fuck it !

Vous imaginez si l’industrie du bâtiment ou celle de l’automobile tournaient sur les mêmes principes ?

La moitié des dessins industriels faits par des bloggers, des étudiants, des retraités, des profs de lycées, des géographes, de biologistes et des postes administratifs ?

Des immeubles et des voitures dont des pièces sont fabriquées par des potes qui chattent sur IRC et s’en occupent quand ils ont le temps ? Gratuitement. Y compris le service après-vente.

Alors que les usagers veulent toujours plus: des normes sismiques et de la conduite autonome. Tout le monde le fait, alors la maison de campagne et la fiat punto, c’est mort, personne ne l’utilisera.

Difficile de maintenir la qualité à cette échelle.

Il y a tellement de demandes de dev, jamais assez d’offres, de ressources toujours limitées.

Et ça grossit. Ça grossit !

Aides techniques

Ceci dit, à l’échelle de la PSF, ça aurait dû être évité.

Avant d’aborder les aides techniques, il serait bon d’arrêter les conneries. Je me répète, mais c’était une vaste dauberie de faire passer async/await en mot clé avant Python 4.

J’ai parfaitement conscience du besoin de faire progresser un langage pour ne pas rester coincé dans le passé. Je suis pour async/await, très bonne idée, superbe ajout. Mettre un warning ? Parfait ! Mais on respecte semver s’il vous plait. Si vous avez envie de faciliter la transition, mettre un import __future__, et inciter les linters à faire leur taff.

En attendant, pour la suite, Python va faciliter le debuggage.

Par exemple, depuis la 3.7, les DeprecationWarning sont activés par défaut au moins dans le module __main__. Donc un développeur verra ses conneries bien plus rapidement.

E.G:

Imp est déprécié en 3.6, mais sans -Wd, on ne le voit pas:

$ python3.6
Python 3.6.5 (default, May  3 2018, 10:08:28) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp

En 3.7, plein de modules importent imp, mais les DeprecationWarning ne sont pas montrés, car ça arrive dans des codes importés. En revanche, si dans le module principal, vous importez imp:

$ python3.7 
Python 3.7.0+ (default, Jun 28 2018, 14:08:14) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp
__main__:1: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses

Ça donne une info importante, sans foutre un mur de warnings à chaque lancement.

Une autre aide est l’apparition, toujours en 3.7, du mode développement de Python avec -X dev qui active tout un tas de comportements aidant au développement:

  • active -Wd
  • appelle PyMem_SetupDebugHooks
  • active faulthandler
  • active le mode debug de asyncio
  • met sys.flags.dev_mode sur True

Évidemment, tout ça ne sert pas à grand-chose si on ne sait pas ce qu’il faut en faire. Et ça demande du temps et du travail, ce que l’amateurisme ne permet pas forcément.

Enfin je dis ça. La plupart des employeurs s’attendent à tout, tout de suite également. Donc au final, n’est-ce pas la culture générale de notre industrie qui est en train de virer dangereusement vers le vite fait mal fait ?

Même si il y a clairement une question de compétence (un prof de maths est généralement compétent en maths, alors que j’attends toujours de rencontrer un prof d’info qui est capable de mettre quelque chose en prod), la pression du marché a créé des attentes impossibles…

L’informatique n’existe comme secteur économique que depuis quelques décennies, contre des siècles pour la plupart des autres disciplines scientifiques. Pourtant on exige d’elle le même niveau de productivité. Il a bien fallut rogner quelque part, et c’est la fiabilité qu’on a choisit.

Quand il y 20 ans, on rigolait en comparant le debuggage de Windows a la réparation d’une voiture, et la punchline sur le redémarrage, ce n’était pas grave: un peu de virtuel dans un monde plein d’encyclopédies papier, de cabines ou bottins téléphoniques et autres cartes routières.

Aujourd’hui que notre monde entier dépend du fonctionnement de nos conneries codées à l’arrache, c’est plus emmerdant. Et ça explique aussi pourquoi le téléphone de ma grand mère fonctionne toujours mieux pour faire des appels que mon putain de smartphone a 600 euros. Mais je peux draguer une meuf par texto en faisant caca à l’aéroport. Tout a un prix.

27 thoughts on “La débâcle de async en 3.7

  • Anh Onÿm

    “(un prof de maths est généralement compétent en maths, alors que j’attends toujours de rencontrer un prof d’info qui est capable de mettre quelque chose en prod)”

    Que dois-je en conclure, de la part d’un formateur python?^^

    Sympa et intéressant, merci pour cet article plus “philo” que d’habitude, ça change et comme on dit, il faut varier les plaisirs!

  • ZZelle

    c’est ballot de ne pas apprendre de ses erreur passées.

    La 2.7.9 a déjà posée problème car elle introduisait des changements sur le comportement par défaut (check des certificats serveur entre autres) non-rétrocompatible mais on pourrait (presque?) le justifier avec des arguments de sécurité.

    La 3.7 introduit des changements majeurs dont la justification me semble très discutable … il aurait été préférable de suivre la même stratégie que pour print entre la 2.X et la 3.X avec un import __future__ pour activer le comportement 3.X en 2.X.

    • Victor Stinner

      L’implémentation de async/await en tant que keyword mais pas vraiment dans Python 3.5 pose de vrais problèmes. Plusieurs codes légitimes lèvent une SyntaxError simplement parce qu’il ne s’agit pas de mot clé. Ajouter un __future__ résoud ce soucis ok. Par contre, ça ne résoud en rien le fait qu’un jour il faut vraiment que ça devienne un vrai mot clé par défaut pour corriger les bugs du parseur et arrêter de cacher la misère.

  • Sam Post author

    > Que dois-je en conclure, de la part d’un formateur python?^^

    Pour être honnête, je ne confierais pas de projets à nombre de mes confrères formateurs. La vérification des profiles des formateurs est minimaliste, et on retrouve vraiment n’importe quoi dans le métier.

  • =°.°=

    Punaise je viens de lire l’article et j’en suis encore à réfléchir au fond. Et je parle pas du caca dans l’aéroport.

    Super article

  • Brice

    Dans ton retour de `python -Wa`, t’as un package (ruamel) qui envoie quasiment toutes les erreurs.
    Mais à part celui-là, c’est pas la folie, c’est même que des choses qu’on est heureux de recevoir, 100% DeprecationWarning (enfin, que dire de la deprecation dûe à l’usage d’une ancienne feature uniquement pour afficher un texte dans la console, texte qui devrait probablement plutôt être loggé, d’ailleurs) :

    python3.6 -Wa
    Python 3.6.5 (default, May 3 2018, 10:08:28)
    [GCC 5.4.0 20160609] on linux
    Type “help”, “copyright”, “credits” or “license” for more information.
    /home/user/Scripts/pythonstartup.py:136: DeprecationWarning: invalid escape sequence \
    print(‘\n/!\ Un session utilisant le store existe déjà. On ne peut pas partager un store.’)
    /usr/share/python-wheels/colorama-0.3.7-py2.py3-none-any.whl/colorama/ansitowin32.py:49: DeprecationWarning: invalid escape sequence \[
    /usr/share/python-wheels/colorama-0.3.7-py2.py3-none-any.whl/colorama/ansitowin32.py:50: DeprecationWarning: invalid escape sequence \]
    /usr/share/python-wheels/colorama-0.3.7-py2.py3-none-any.whl/colorama/ansitowin32.py:49: DeprecationWarning: invalid escape sequence \[
    /usr/share/python-wheels/colorama-0.3.7-py2.py3-none-any.whl/colorama/ansitowin32.py:50: DeprecationWarning: invalid escape sequence \]
    /usr/lib/python3/dist-packages/pip/pep425tags.py:260: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module’s documentation for alternative uses
    import imp
    >>>

    Pour le reste de l’article, j’approuve grandement (et j’ai quelque fois peur de l’avenir de Python dans certaines discussions de Python-ideas, notamment avec les None-aware operators…)

  • Plop

    n’est-ce pas la culture générale de notre industrie qui est en train de virer dangereusement vers le vite fait mal fait ?

    Ça ne me paraît pas du tout nouveau…

    Suffit de voir la gueule de JavaScript pour comprendre. Un langage mal branlé qui fuit de tous les côtés, qu’on rustine à tout-va, et c’est ça qu’on nous oblige à utiliser dans tous les navigateurs. Il y a bien un gros effort pour tenter d’améliorer le bidule, mais on bâtit quand même sur un gros paquet de merde.

    Et c’était comme ça avant JavaScript. Qui n’a jamais vu d’appli métier codée avec les pieds ? (“Oh, vous avez fermé l’application en cliquant sur la croix rouge en haut à droite, il ne fallait surtout pas, vous avez tout planté…” Du vécu.)

    Écrit il y a huit de ça : https://ploum.net/ploum-en-j2ee/

    Vous imaginez si l’industrie du bâtiment ou celle de l’automobile tournaient sur les mêmes principes ?

    Pour l’automobile, je ne connais pas, ça a l’air assez sérieux.
    Mais dans le bâtiment je ne connais pas grand-monde qui n’ait pas eu à se plaindre de professionnels qui faisaient vraiment n’importe quoi dès qu’on avait le dos tourné.

  • Bakaniko

    Bonjour,

    Une petite coquille a été oubliée:

    “Diffile de maintenir la qualité à cette échelle.” => “Difficile de maintenir la qualité à cette échelle.”

    Merci pour vos articles.

  • dineptus

    Pour le bâtiment en fait c’est pareil. C’est même tellement similaire : les gens qui n’y connaissent rien trouvent que globalement ca marche bien, sans se rendre compte que c’est un bordel pas possible avec plein de détournements de règles, d’arrangement louches et de trucs qui tiennent pour le moment mais sans vrai gaaranties futures.

    D’ailleurs je serais curieux de voir un project de bâtiment qui se déroule comme prévu et livré en état parfait.

    Quand tu vois qu’à Paris ils sont toujours pas capable de faire des stations qui ne sont pas infilrées près 2 mois, et qu’à Stockholm ils ont du fermer la station centrale de trains de banlieu au bout d’un an aprce que tous les escalators avaient rouillés et qu’un était du coup parti en arrière quand une pièce a laché …

    Franchement je dirais même que l’informatique est bien plus rigoureuse que la construction.

  • Nedry

    ” Il a bien fallut rogner quelque part, et c’est la fiabilité qu’on a choisit.”

    Oui, enfin ce n’est pas vrai dans tous les secteurs. On doit quand même pas faire du soft d’aéronautique comme on fait un crud pour un site web vitrine (enfin j’espère, ahahah…)

    Comme disait Ian Malcom: “Oui mais, John, quand les pirates des Caraïbes se détraquaient, ils ne dévoraient pas les touristes !”

  • phil philou

    +1000 sur le fond.
    On se prépare des lendemains qui déchantent et peu de gens le voient venir.
    Merci pour cet article, je surlike.

  • JulienG

    Hum. C’est mon premier commentaire et je risque un tampon « hors sujet ». Mais après tout c’est pas mal si j’ai un tampon dès le premier (non?) ! ;)

    Tout d’abord je trouve que c’est un bel article – ou au moins utile. Sans flagornerie aucune (si je suis peut-être suce-boules, c’est du fait d’être gay, sinon j’ai une franchise souvent déconcertante).

    Il met en évidence que l’informatique est, reste, se compare, ne sort pas, continue, (mettez le verbe que vous voulez) dans la perspective d’un réseau imminemment humain. Parce que le développement est (encore quelques temps), de la pensée humaine que l’on code / programme. Et que les limites de développements, sont souvent les limites de l’abstraction que nous avons nous-même (développeurs pro ou amateurs) et de nos propres expériences ou connaissances (forcément limitées). C’est-à-dire que l’on tire une suite de tâches, en réalité d’informations, qui doivent être exécutées, de notre propre savoir. Ce n’est pas rien si l’on parle « d’exécution » d’un logiciel, de « requêtes » ou de « programme » (renvoi à une notion d’ordres, d’imposer quelque chose, de suivre une volonté extérieure à la sienne). Un algorithme est toujours une représentation mathématique, logique plus exactement, d’une volonté.

    Si demain une « IA » (kesako?), se met à programmer, alors une grosse partie de ce que j’indique ici sera nul et non avenu. En attendant, dissertons un peu.

    Récemment j’écoutais le récit du procès de Pierre Laval par Franck Ferrand sur Europe1, et notamment la défense de ce dernier. Un peu plus loin, je tombe sur un article évoquant cette période d’une « dictature pluraliste », exprimé Stanley Hoffman. Je trouve ça intéressant, j’approfondis le sujet, quelques jours avant de tomber sur l’article du blog.

    Une dictature, c’est la volonté d’un (ou d’une très courte minorité), sur un ensemble d’individus. Hoffman – de ce que j’en ai compris –, évoque le terme de « pluraliste » ici car il n’y a pas véritablement une orientation « claire », au sens d’une pureté idéologique (il parle en universitaire, sans jugement de valeur), mais une conjonction multiples – d’autant que l’État délitescent, minés par la désertion et l’apurement de tout ce qui ressemblait à des démocrates (même de loin), la situation européenne inhumaine, ne renforçaient pas vraiment les élans intellectuels… Passons.

    La dictature recouvre parfois des raisons d’adhésion (religieuse le plus souvent : monarchie, théocratie, etc ; parfois impériale au sens coloniale ou encore d’idéologie), et majoritairement par l’expression de la force (soit en privant d’une liberté, soit au contraire en permettant une exaction).

    A l’inverse, la démocratie s’essaie en permanence à faire émerger par le débat, une volonté populaire au sens où le plus grand nombre décide (soit de manière représentative, comme en France, soit de manière directe, comme en Suisse → qualités et défauts dans les deux cas).

    La démocratie n’est pas du tout la recherche d’une « vérité » (ce qui plutôt le cas d’une dictature, qui souhaite légitimer son maintien), mais d’une décision légitime. D’ailleurs il existe des gardes-fous (constitution, Conseil d’État, Conseil constitutionnel, tribunaux administratifs, etc), qui rappellent soit à une loi existante (garder une cohérence) soit pour maintenir certaines valeurs communes (celles fondamentales, qui sont des débats sans fin), sans pour autant gouverner en lieu et place.

    Ce que j’exprime là me semble complètement dans le cœur de l’article : qui (ou quoi) décide ? Quand ? Comment ? Quelle procédure ?

    Asyncio est révélateur que Python semble être plus rapide dans son développement, moins « sûr » au sens des qualités d’un langage qui avance en respectant son propre passé, en tout cas de ce que j’en lis ici. Peut-être parce que sa popularité atteint un certain record et que l’explosion des utilisateurs, saturent les canaux habituels (les listes de diffusion). Bref Python dépasse le cadre du développeur pour devenir celui d’un langage « populaire ».

    Finalement ton article Sam, à mon sens, il rappelle que l’informatique de développement, de programmation, a le choix permanent :
    → soit d’être une science, c’est-à-dire arbitrable de manière strictement objective (objectivée). Après tout, tu peux comparer la qualité du code (pas seulement son efficacité au sens du traitement de l’information, mais aussi sa lisibilité, sa maintenance, le choix d’un langage dans une situation donnée, etc), définir des protocoles d’utilisation, faire de la recherche sur les outils conceptuels ;
    → soit d’être un outil, c’est-à-dire de répondre strictement et avant tout à un usage (ici un besoin humain de communiquer et de gérer).

    Si tu pars du principe que c’est avant tout une science, le côté « dictatorial » – renforcé par l’organisation jusqu’à récemment de Python (Guido van Rossum, le « dictateur bienveillant à vie ») –, invite à réduire le nombre de personnes aux « sachants », qui sont eux-même reconnus par une maîtrise réellement technique et informatique (bref ce que l’on pourrait qualifier d’universitaires, même si l’on en a pas toujours le titre ou l’objectif). Un groupe restreint, qui peuvent être élus ou désignés par un collège de fondations peu importe, d’universités, mais qui « valide » et décide d’un avenir commun à tous (avec des questions associées : quels pays représentés ? Quel niveau attendu ? Comment justifier du niveau ? etc). En tout cas, tu peux difficilement projeter aujourd’hui une validation démocratique direct (donc s’appuyant sur notre propre passion, intérêt, engagement) dans un tel cas (cf ce que je disais sur les listes de diffusion plus haut).

    Si tu pars du principe que c’est un outil, alors chacun prend un peu ce qu’il veut, voire organise des forks du langage (un peu à la manière de NodeJS si j’ai bien compris?), souvent pour de mauvaises raisons, avec des résultats qui tournent autour du concept unique de « ça fonctionne » ! Ccar l’essentiel est moins de répondre à des canons d’utilisation (qui peuvent arriver après), mais d’abord à des besoins très immédiats.

    Personnellement je crois à la première voie : offrir une vision plutôt restrictive, avec une liberté de débat suffisamment grande pour exprimer tout de même ce qu’attendent les utilisateurs au quotidien (le sens de la « dictature pluraliste » en quelque sorte).

    Car un langage « parfait » mais qui n’aurait ni utilisateur, ni fonction, n’aurait donc pas d’attentes et pas seulement pas d’intérêt : c’est un langage mort. Vierge même.

    Un crochet sur les OS fixes, à qui on peut appliquer cette même grille de lecture :
    → Windows ou le nivellement par le bas, qui s’évertue à être partout et dont la qualité première n’est pas celle de son code, mais surtout de dégager l’utilisateur de toute notion de contrôle (une infantilisation pour moi), qui est un dictateur « populaire » ;
    → Apple ou le nivellement par le haut, qui cible les clients à hauts revenus en priorité et joue d’un prestige (que je trouve très relatif…) de ses produits pour un environnement très maîtrisé mais unique, qui forme une sorte d’aristocratie (aucune alternative, des versions qui se suivent sans pouvoir maîtriser grand-chose, car lié au produit qui l’utilise) ;
    → Linux, un sublime bordel vraiment démocratique, mais qui passe son temps à voir naître et mourir des projets, parfois intéressants, souvent moins, qui se veut exigeant avant tout sur certaines valeurs. Mais qui gagne surtout dans la compétition côté serveur, et qui est (ou reste) finalement une sorte « d’élite » technique pour beaucoup d’utilisateur.

    Pour conclure et revenir à ce que tu indiques, c’est assez marrant – mais j’ai probablement un humour assez douteux – de comparer le développement informatique à ce qui se passe dans l’économie « réelle » (au sens de sensible, palpable).

    Cela prouve deux choses : 1. la connaissance n’est pas quelque chose qui se comporte tout à fait comme le matériel (ce que je t’apprends, ne me dépossède pas mais te permet de posséder à ton tour → on « copie » toujours de l’information).

    2. Tu as raison, l’explosion de l’usage rend le cahin-caha des débuts (éloignés certes), problématiques aujourd’hui, et que le bénévolat ne peut pas (ou plus) résoudre. J’oserai même dire : c’est une nécessité pour poursuivre notre évolution humaine (sans blague : pensez aux réseaux d’eau, d’énergie, les télécoms, etc).

    Mais finalement ce qui arrive à Python, c’est ce qui est arrivé à Internet : l’explosion des usages, des attentes, lors de la bascule au « grand public ». Internet s’y transformé, pas toujours en bien, mais aussi parce que l’attente était de tirer les prix vers le bas pour élargir toujours le nombre d’abonnés. Et donc la qualité du service, de résoudre l’équation par la publicité, qui s’est imposée.

    Aujourd’hui il y a trois Internet pour moi :
    → le continent européen, vaguement administré via des réglementations comme la RPGD,
    → la liberté foutoir américaine, et sa prime au plus aisé,
    → le contrôle asiatique (je pense notamment à la Chine) et son grand « firewall » et sa notation « citoyenne », et sa prime au plus grand respect des règles publiques (humf…).

    Ce sont peut-être les mêmes routeurs, les mêmes câbles, le même « réseau de réseau » mais franchement, les contextes d’utilisation, les accès (je parle même pas de l’Afrique, qui passe de rien aux réseaux mobiles), sont tellement différents, les attentes tellement différentes, que je ne serais pas surprise que finalement, un jour, les langages se scident aussi. Ou à tout le monde que l’accès à des langages, deviennent un accès à une élite (pas bien!).

    Pour ma part, je crois que l’équipe du « cœur » de Python devrait avoir en priorité : 1. le financement de son indépendance (mais alors franchement réelle), en s’appuyant sur des réseaux universitaires et des privés (en limitant par exemple le montant des dons, pour éviter qu’une main-mise finisse par être possible par un industriel unique) ; et 2. ne pas se disperser dans une validation qui ne regarde finalement pas trop le commun des mortels (j’en suis un moi-même). Ce qui ne veut pas dire ne pas nous écouter, mais après tout, Python c’est de l’informatique, et l’informatique, ça reste de la science technique.

    Si on veut que ça marche, et que ça marche bien, il faut savoir rester modeste. Et il faudra peut-être aussi un jour, penser que le monde technique n’est pas détaché de notre monde humain : développer, c’est imposer une volonté à la machine. C’est imposer nos « valeurs » à notre machine…

    Conclusion : vous vous rappelez en début de commentaire (y’a longtemps) du suce-boules ? Ben suce-bites aussi (envoyez vos nudes en DM les mecs! … quoi ? y’a pas de DM ?!).

  • Victor Stinner

    Euh l’article est un peu survendu, Python 3.7 n’a pas fait tomber le moindre avion ni tué personne. J’ai vaguement entendu parler de qq. soucis dans Twisted avec async qui est devenu un mot clé, mais ils ont trouvé une solution élégante qui est compatible avec toutes les versions de Python et une nouvelle release est sortie. Rien d’anormal suite à une release majeure de Python (3.x).

    La question de fond est pourquoi le mot clé n’a pas émis de warning avant ? Euh il y a des warnings depuis 3 ans (Python 3.5).

    La question devient : pourquoi les warnings ne sont pas activés par défaut. Une réponse est que la majorité des devs n’en fichent des warnings et au final le résultat est pourri pour tout le monde. Ça fait des annés que je remonte et corrige des warnings dans pip.

    Une autre réponse est la PEP 565 de Nick Coghlan qui affiche les warnings par défaut : https://lwn.net/Articles/740804/

    Perso je n’aime pas cette PEP alors j’ai proposé l’option -X dev. Vos tests doivent passer avec -X dev ou PYTHONDEVMODE=1 et puis c’est tout.

    Ignorer les warnings pendant 3 ans puis pleurer que personne ne vous avait rien dit, bon, bah super.

  • Victor Stinner

    “Je me répète, mais c’était une vaste dauberie de faire passer async/await en mot clé avant Python 4.”

    Le Python 4 “on va foutre tous les changements incompatibles dans la même release” a été testé par le passé. Résultat : la très grande majorité des dev a refusé Python 3 justement parce que ça cassait tout.

    Maximiser les changements incompatibles par release est une erreur, on ne le fera plus dans Python.

    Les changements incompatibles sont maintenant programmés et suivent un cycle lent d’au moins 2 releases voir 3. Pour async/await en mot clé, on parle de 3 releases entre l’introduction du warning et le cassage de compatibilité.

  • Victor Stinner

    Le cas de True/False de Python 2 est intéressant.

    Le type bool, True et False a été ajouté en 2003 dans Python 2.3 par la PEP 285. En 2018, 15 ans plus tard, “while True:” reste plus lent que “while 1:” en Python 2.7 parce que Python 2 a besoin d’un LOAD_GLOBAL bien lent pour lire la valeur de True *à chaque itération*… au cas où True n’est pas vrai. Pour la même raison, le compilateur est incapble d’optimiser un code trivial comme “if False:” (évalué à l’exécution donc).

    Python 2.7 reste inefficace pour un truc aussi fondamental que True/False parce sue personne n’a eu le courage de casser la compatibilité ascendante. Perdre le support de code rétro compatible avec Python 2.2 (sans type bool).

    Je vous laisse méditer.

  • Sam Post author

    Hello victor,

    Pour la partie sur les warnings, en fait c’est exactement ce que je dis dans l’article.

    En revanche, pour la partie sur l’incompatibilité, le problème vient du non respect de semver. Tu vois le problème à l’envers: ne groupons pas tout au bump de version majeure.

    Mais une version majeure n’est pas une fin en soit, c’est une indication technique (et parfois commerciale, mais Python n’a pas ce problème).

    Donc le problème est l’inverse: ce n’est pas, groupons tout au bump de version majeure, mais bumpons la version majeure quand on pête un truc.

    Pour des raisons culturelles, on aime pas incrémenter la version majeure des logiciels trop souvent.

    Mais ça serait préférable d’être à un Python 6 ou 7 déjà, et d’avoir clairement marqué le coup quand on a pété la compat.

    Le coup de “on est seulement en Python 3” mais en fait on a déjà cassé la compat 6 fois, ça tient plus à mon sens du tour de force psychologique (ou d’un sens d’esthétique geek douteux) que d’une stratégie technique judicieuse.

    Rien à voir mais: tu feras ton sprint documentation à la pyconfr cette année aussi ?

    • walt

      @Sam totalement d’accord avec toi sur le fait qu’on devrait passer à une v4 en théorie.
      Après j’ai remarqué que suivre ce genre de versionning, psychologiquement, ça freine les gens à migrer.
      Je prends l’exemple d’Angular, maintenant pour le moindre truc on passe de la V4, à la V5, à la V6.
      A chaque fois, y’a toute la communauté qui stresse parce qu’elle croit que ça va être un “gros” changement, avec de la migration lourde (sûrement la faute au passage de Angular 1 à 2) alors qu’en fait y’a que dalle.
      Donc c’est débile mais de passer de Python 3.6 à 3.7, tu sais que ça va être smooth, passer de Python 3.6 à Python 4, tu t’attends aux mêmes problèmes que le passage de Python 2 à Python 3.
      Si ça avait été comme ça depuis le début, why not, mais en faisant ça à partir de maintenant, tu dois réussir à faire changer le mindset de toute une communauté, pas évident.

  • TripleHOP

    «” Il a bien fallut rogner quelque part, et c’est la fiabilité qu’on a choisit.”»

    Pour maintenir le taux de marge, on réduit sur le reste : la qualité, la maintenance, la sécurité, la masse salariale.

    Si vous voulez que cela s’améliore, ne voter plus pour des gros cons de néo-libéraux.

  • Sam Post author

    @walt:

    > Donc c’est débile mais de passer de Python 3.6 à 3.7, tu sais que ça va être smooth

    Sauf que ça l’est pas. Smooth.

    En gros là on fait semblant. On cache sous le tapis.

    C’est du marketing.

    J’aime déjà pas beaucoup le marketing, mais dans mon langage de programmation encore moins.

  • yoshi120

    Un article sur José Ortega y Gasset un philosophe espagnol des années 30 devrait aider et notamment cette citation sur la science en général mais applicable à l’informatique :

    https://philitt.fr/2017/06/13/jose-ortega-y-gasset-contre-la-barbarie-de-la-specialisation/

    «Car la science a besoin de temps en temps, pour régler son propre accroissement organique, d’un travail de re-consitution ; or, je l’ai déjà dit, ce travail requiert un effort d’unification chaque fois plus difficile, qui chaque fois embrasse des régions plus vastes du savoir total.»

    José Ortega y GassetLa révolte des masses (1929)

  • Machin

    > Mais je peux draguer une meuf par texto en faisant caca à l’aéroport.

    Pour l’instant, mais Google veille, ça devrait se gâter pour ce qui est de l’odeur avec la nouvelle génération de ISamwei à capteurs environnementaux et réalité augmentée qui ne devait pas tarder à trouver le chemin du portefeuille des addicts qui ont un smartphone de déjà trois mois et que du coup c’est juste trop pas possible.

    Cela étant on ne pourra pas non plus se faire draguer par une nénette en train de pisser. alors il y a peut-être une forme de justice dans tout ça. Va savoir.

    Plus sérieusement, bon article qui sait sortir de la bulle strictement technique pour mettre les choses en perspective.
    Bin oui, l’informatique, au sens large, c’est comme tout le reste; sous le joug de la Nouvelle Economie qui fait tant saliver les perroquets néolibéraux et autres économistes/idiots utiles, dont la caractéristique principale est de se mettre eux-même à l’abri des potions amères dont il préconisent l’emploi généralisé avec un touchant enthousiasme.
    Et donc:
    1/ si ça se fait à deux ça peut sûrement se faire à un.
    2/ on n’embauche plus, on travaille sur projet avec des sbires/mercenaires/stagiaires mal dégrossis et pas impliques pour un rond qu’on lourde (d’où l’absence d’implication, entre autres) à la fin du projet.
    3/ les brouzoufs que l’on met dans un projet c’est autant qui échappe aux petits doigts rapaces de l’Actionnaire omnipotent et ça c’est le Mal absolu.
    J’en oublie un tas sûrement qui ne contribuent en rien à la qualité du produit fini.

    Maintenant quand on parle de vite fait mal fait, mon smartphone android brut de fonderie met tous les jours ou presque, à niveau les mêmes gougueuleries.
    Alors soit Google rajoute de nouvelles fonctionnalités tous les jours, mais j’en doute, soit corrige des bugs tous les jours ce qui ne choque apparemment que moi, donc… l’exemple vient de tout en haut.

    A part ça, bon blog avec des articles utiles pour moi, pythoniste récent et que de loisir. Le tout dans un curieux écosystème qui me rappelle un peu le Usenet de la grande époque.
    Avant l’invasion de presque tous les forums techniques par les quasi illetrés narcissiques fessebouquistes.

    Bon, sur ce, il est temps d’aller nourrir mon Vax780 apprivoisé.

  • Réchèr

    Le bonjour,

    Même si je ne peux avoir la prétention d’être un grand pythonien, j’ai quand même fait ou participé à beaucoup de projets divers, personnels et professionels :

    – des sites web en flask, d’autres en django,
    – des petits jeux avec pygame,
    – des scripts de validation de trucs aéronautiques (aucune idée précise de ce qu’était les “trucs” en question, j’avais le strict minimum dans des docs de specs ultra-formatés),
    – un tout petit peu de cartographie et de SIG,
    – une UI sous Windows dialoguant avec le bazar MS Office grâce à pywin32,
    – un poller SNMP sur des équipements réseaux tellement étranges que du coup Nagios tout seul ne suffisait pas,
    – un plug-in de CTFd (framework pour des jeux de Capture The Flag),
    – plein plein de petits scripts de traitement de données pour me faciliter la vie,
    – etc.

    À aucun moment je n’ai eu besoin de async/await. Et je n’ai jamais cherché à apprendre à m’en servir.

    Je ne dis pas que c’est inutile. Je dis que, peut-être, pour la plupart des développeurs python, ce ne sera pas si grave si on doit attendre la version 3.69, ou la 69.1, ou même la 69.69 pour avoir un async/await correct, stable et documenté.

    Pourtant, l’asynchrone, je connais un minimum. Je suis comme tout le monde, j’ai bien été obligé de bouffer du javascript.

    Donc pas la peine de se prendre la tête si on est actuellement un peu dans le flou concernant async/await. Le reste du langage reste très bien.

    J’en profite pour dire un grand merci à Guido Van Rossum, Victor Stinner et tous leurs potes.

    hashtag tout_le_monde_s_en_fout : à l’époque plus ou moins lointaine de mes études, j’ai eu l’occasion de suivre les mêmes cours que Victor, dans la même école. Mais je n’ai pas trop profité de cette proximité, car je passais beaucoup de temps à tenir le bar du foyer et à squatter les ordis des salles informatiques pour télécharger des images de femmes rondes que je ramenais ensuite sur mon PC à l’aide de disquettes. Internet était pas aussi répandu. Ça nous rajeunit pas.

    Gros bisous à tous !

    • Victor Stinner

      Coucou Réchèr ;-) J’ai de très bons souvenirs de l’UTBM et ses soirées. J’avais direct fait le lien la première fois que j’avais vu ton nom en commentaire y’a plusieurs mois !

  • TripleCON

    Si ton script brûle, ce n’est pas à cause de la version de Python, c’est que ton script est en bois bien entendu !

  • Jojuss

    La programmation n’étant pas mon domaine de prédilection (je suis ingénieur mécanique), les arcanes du fonctionnement de fonctions comme async/await ça m’en touche une sans faire bouger l’autre, cependant il y a un truc que j’ai trouvé intéressant (pour moi) dans cet article.

    Vous parlez du fonctionnement de l’informatique qui est en général beaucoup basé sur le gratuit et le bénévolat et faites le parallèle avec les autres champs de l’industrie. Il est vrai qu’il n’y a que dans ce domaine où l’on retrouve tant de “bonne volonté?” et je me demande bien pourquoi ?
    Tout le monde connaît bien l’adage : “Tout travail mérite salaire”, et bien pourquoi vous les informaticiens mettez tant de coeur à produire des choses opensource ?

    Je trouve ça formidable qu’il y est cette volonté de produire du contenu disponible pour tous dans l’informatique, mais dans un monde capitaliste, ça va un peu à contre courant, j’aimerai bien savoir quoi :)

    Sinon toujours un plaisir d’apprendre de nouvelles choses sur ce site !

    • brliron

      C’est une question intéressante. A mon avis, il y a plusieurs raisons à ça. La 1ère, c’est la facilité du partage.
      Imaginons que les coques de téléphones n’existe pas. Tu as déjà cassé 2 téléphones en les faisant tomber, et tu aimerais éviter de casser le 3ème. Du coup, tu vas essayer de bricoler un truc, avec de la mousse, du scotch, et peut-être un peu de carton, pour que quand ton téléphone tombe, la mousse absorbe le choc.
      Et une fois que tu as fait ça, ça marche, tu as tout content, ça a déjà sauvé ton téléphone 2 fois. Tu vas probablement recommander ton truc à tes amis, en leur disant à quel point c’est génial et tout. Mais est-ce que tu vas acheter des gros stocks de mousse et de scotch, et produire des centaines d’exemplaires que tu vas envoyer toi-même (en payant la livraison) à des gens partout dans le monde ?
      Pour un informaticien, oui. C’est gratuit, il suffit de faire 3 clicks sur github, de taper 2 commandes et le monde entier peut utiliser ton machin.

      La suite, c’est que vu que tu es fier de ton machin, tu aimerais le rendre encore meilleur. C’est comme ça que tu te retrouves à faire de la correction de bugs, des améliorations etc.

      En parlant de fierté, il y a aussi la fierté de participer à quelque chose qui aidera des gens.

      Une autre raison, c’est que pour certains, la programmation est un loisir. Si ça te paraît étrange, prenons juste un autre loisir tout simple mais très répandu : les jeux du journal / programme télé, comme les mots croisés et le sudoku. Le but de ces jeux est de faire travailler le cerveau, que ce soit la mémoire des mots pour les mots croisés ou la logique pour le sudoku. Les gens aiment bien faire travailler leur cerveau de temps en temps, dans leur temps libre, et ils aiment aussi réussir des choses. Et la programmation est un bon travail de logique, avec un but à atteindre : que le truc fonctionne.

      Et enfin, c’est par idéologie. Et ça, c’est pas propre à l’informatique. Il y a des gens qui se battent pour sauver les pingouins du réchauffement climatique. Il y a des gens qui font tout ce qu’ils peuvent pour soutenir un candidat aux présidentielles dont ils aiment les idées. Et il y a des gens qui se battent pour qu’on puisse naviguer sur internet sans avoir sa vie privée complètement dévoilée. Ainsi que des gens qui veulent faire en sorte qu’utiliser un ordinateur au quotidien soit plus simple pour tout le monde. Et ce dernier est beaucoup plus simple que les autres. Pas besoin de réussir à changer les idées de 80 millions ou même de 7 milliards de personnes, juste à taper des trucs sur un clavier.

      Voilà mon avis sur la question

  • mik

    Je suis en train d’apprendre le code donc je suis pas une “tête” dans le domaine. ^^”

    Mais je pense qu’à ce niveau le mieux à faire pour les application en production est de ne pas upgrader python, tout simplement (comme s’il était passé en V4) ?

Comments are closed.

Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.