Journal Guido van Rossum se retire de la direction de Python

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
65
12
juil.
2018

Guido van Rossum est le créateur du langage Python. Il joue le même rôle que Linus Torvalds pour le noyau Linux puisqu'il est le décisionnaire en dernier ressort (le BDFL : Benevolent Dictator For Life) de toutes les modification qui sont incluses dans Python.

Guido vient d'annoncer qu'il mettait fin à ses fonctions de BDFL. Il semble qu'il soit un peu fatigué des controverses autour de la PEP 572 visant à introduire les "Assignment Expressions" dans Python et il a saisi cette occasion pour se retirer.

C'est maintenant aux membres de la core team de décider comment ils vont s'organiser pour prendre les décisions au sein du projet.
Comme le dit Guido :

So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?

Ce sera intéressant de voir ça…

  • # ouaa je ne connaissais pas la notation yoda! trop cool

    Posté par  (site web personnel) . Évalué à 5.

    si vous non plus vous ne connaissiez pas l'article wiki : https://en.wikipedia.org/wiki/Yoda_conditions

    • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

      Posté par  (Mastodon) . Évalué à 2. Dernière modification le 13 juillet 2018 à 11:05.

      j'avais vu passer sans comprendre l'intérêt. même si au final je préfère la méthode traditionnelle, au moins j'ai compris :)

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

        Posté par  . Évalué à 8. Dernière modification le 13 juillet 2018 à 12:28.

        j'avais vu passer sans comprendre l'intérêt

        1. Compenser les défauts d'un langage mal conçu où une typo à la con comme = à la place d'un == est syntaxiquement valide mais ne fait pas du tout ce que tu attendais. En inversant tu t'assures que le compilo ne laissera pas passer le truc
        2. Compenser les défauts des développeurs n'étant pas foutu de gérer correctement la nullité des types dans les langages dont le système de type est lui mêmes mal foutu. Typiquement en Java tout le monde est fier de foutre du Yoda partout au cas ou un null se baladerait quelque part sans jamais se demander pourquoi c'est normal que tout puisse être null partout sans aucune raison, indice ou autre… Mauvaise solution à un problème que tu ne devrais pas avoir.

        Tu pourras objecter que les deux usages s'invalident par de tests corrects et une utilisation saine de son système de type… et je ne te donnerais pas tord.

        • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

          Posté par  . Évalué à 7.

          Avertissement : j'aime le C et j'utilise la notation Yoga (dont je ne connaissais pas le nom).

          Tous les langages ont des défauts, pour prendre le langage dont il est question, une petite erreur d'indentation (le caractère tabulation) peut créer des effets tout aussi indésirables. Je pense notamment à une mauvaise indentation de la dernière instruction d'une boucle.

          Dire que le langage C est mal conçu est, à mon avis, une mauvaise perception du langage.

        • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

          Posté par  . Évalué à 4.

          Voila pourquoi Kotlin c'est la vie

        • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

          Posté par  . Évalué à 5. Dernière modification le 14 juillet 2018 à 09:07.

          Typiquement en Java tout le monde est fier de foutre du Yoda partout au cas ou un null se baladerait quelque part sans jamais se demander pourquoi c'est normal que tout puisse être null partout sans aucune raison, indice ou autre… Mauvaise solution à un problème que tu ne devrais pas avoir.

          C'est vrai, ça ne sert à rien de prendre des précautions, il suffit de ne pas coder des bugs et d'avoir des tests unitaires exhaustifs.

          • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

            Posté par  . Évalué à 5.

            On est pas obligé d’en être fier, et on peut aussi utiliser les annotations et Optional (même si cette classe est assez risible dans son concept…).
            Java a clairement un problème de NPE.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

              Posté par  . Évalué à 4.

              On est pas obligé d’en être fier, et on peut aussi utiliser les annotations et Optional (même si cette classe est assez risible dans son concept…).

              Pourquoi est-ce que le concept est risible?

              Ca ressemble a ce qu'on voit dans les languages fonctionnels et qui marche assez bien. Il y a meme une methode map et une flatMap.

              • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

                Posté par  (site web personnel) . Évalué à 5.

                Peut-être veut-il dire que c'est risible d'introduire Optional en Java en se croyant à l'abri des NullPointerException alors que c'est pas si simple. En tout cas en Scala il y a évidemment Option, mais le problème c'est que, tant que tu fais du Scala (du moins idiomatique, si tu commences à renvoyer null dans du Scala, on est pas sortis= du sable) t'es pépouze, mais dès l'instant où tu t'interfaces avec du code Java (ne serait-ce qu'en utilisant une bibliothèque super utile), tu n'as plus de garantie qu'une fonction avec type de retour Foo ne te balancera pas un null :(

                Bon s'il trouve globalement le concept de coder l'absence dans le système de type, au lieu de devoir faire du runtime, risible, le truc risible c'est lui.

              • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

                Posté par  . Évalué à 6.

                Ca ressemble a ce qu'on voit dans les languages fonctionnels et qui marche assez bien. Il y a meme une methode map et une flatMap.

                Optional en Java n'est pas, et n'a jamais été conçu, d'être l’équivalent d'Option en Scala ou tout autre option type. Son usage est uniquement destiné à indiquer qu'une méthode peut retourner quelque chose ou rien. Utiliser Optional comme paramètre ou membre est un anti-pattern. Ça a été discuté un million de fois lors de son introduction et tu trouveras facilement les arguments en cherchant un peu. Même en type de retour tu verras rapidement les limitations. Combine le résultat de deux fonctions retournant un Optional juste pour rigoler.

                En fait, Optional en Java ne résout pas grand chose au prix d'un stress supplémentaire sur le GC en attendant les value types. C'est juste un gros pansement: hey on a complètement merdé notre système de type sur les null et on introduit un gros wrapper pour limiter les dégâts. Si tu résous le problème de gérer correctement la nullité dans les autres cas autre que le type de retour d'une méthode alors Optional devient superflu. Le moins mauvais qu'on puisse faire en Java sont effectivement les annotations de nullité de la JSR 305 / Intellij / Eclipse. Ça passe pour les paramètres et type de retour mais très limités pour les variables et membres d'instance puisque ca manque de concept comme le non null monotone. Celles du https://checkerframework.org/manual/#nullness-checker sont mieux mais il y'a toujours des endroits qui restent merdiques et ingérables mais on arrive à avoir 80% du code sans trop surprise en étant un poil carré. Ca reste assez bancale…

                • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

                  Posté par  . Évalué à 3. Dernière modification le 15 juillet 2018 à 10:15.

                  Ça a été discuté un million de fois lors de son introduction et tu trouveras facilement les arguments en cherchant un peu. Même en type de retour tu verras rapidement les limitations.

                  J'ai checké un peu les discussions et il y a énormément de bruit.

                  L'essentiel est résumé par Sufflope j'ai l'impression, ce n'est pas intégré avec consistance dans la bibliothèque standard (Map.get peut retourner null par exemple) ni dans les bibliothèques tierces.

                  • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

                    Posté par  . Évalué à 4. Dernière modification le 17 juillet 2018 à 00:31.

                    J'ai checké un peu les discussions et il y a énormément de bruit.

                    Si tu veux éviter de relire les 341745 messages de la mailing list, tu as un résumé correct des choix et compromis dans la présentation Optional - The Mother of All Bikesheds by Stuart Marks: https://www.youtube.com/watch?v=Ej0sss6cq14

                    Les points intéressants sont:

                    • Optional is intended to provide a limited mechanism for library method return types where there is a clear need to represent "no result", and where using null for that is overwhelmingly likely to cause errors
                    • We are not trying to solve a much more general problem of a maybe monad or something like that if you are a functional programmer
                    • We are not trying to get rid of null references from Java entirely. Optional does not replace null references
                    • L'impact du boxing sur les perfs (16 bytes overhead + dependant load qui te pourri tout)
                    • L'insistance sur tous les cas où ce n'est pas adapté (presque tous en fait)
                    • L'insistance sur le fait qu'il ne faut éviter le combo isPresent() / get() mais qu'en fait la moitié des cas utiles l'imposent. Ça part des exemples explicites comme l'implémentation lisible du add qu'il a choisi, à des cas implicites. Par exemple si tes méthodes retournent un Optional et que tes méthodes prennent des nullable en paramètre comment crois tu que tu passes de l'un à l'autre ? En passant ton temps à faire des get :( Sur des bases de code réelles, en appliquant la règle de n'utiliser get que si aucune autre méthode n'est applicable, on doit être encore à > 50% de get.
                    • Le fait qu'en fait tout le monde est d'accord qu'on garde null. Optional est juste un pauvre wrapper pour faire compiler l'API des Stream qui sinon ne marchait pas. Comme on a été un poil plus ambitieux, on propose de l'utiliser comme marqueur l'API pour résoudre un autre problème. Sans résoudre grand chose en fait, voir en introduisant de la complexité. En l'état la seule solution à la nullité c'est de bosser sur l'analyse statique de code. Quand tu as résolu ca, Optional devient un non sujet (glass is one-quarter full).

                    Le point commun avec la démission de Guido et la PEP 572, c'est le bikesheding autour du truc :) D'ailleurs ca manque un peu de troll dessus !

              • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

                Posté par  . Évalué à 1.

                ckyl a répondu, mais pour être plus précis: le code est toujours aussi verbeux (plus en fait), le typage devient abscons (tu retourne pas le type que tu veux, mais un wrapper), et en plus faut toujours faire super gaffe parce que tu peux toujours te peter une exception si t’utilise pas orElse().

                C’est super bancale. C’est du même tonneau que dire que le c supporte l’oriente objet parce que on peut avoir des pointeurs de fonctions sur une struct.

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

                  Posté par  (site web personnel) . Évalué à 4.

                  le typage devient abscons (tu retourne pas le type que tu veux, mais un wrapper)

                  C'est quoi ta solution miracle pour représenter "je suis une fonction qui retourne un Foo si ceci et cela, rien si je peux pas", en gardant Foo comme type de retour, mais en évitant qu'en utilisant ce Foo (bah quoi, le type me dit bien que ça renvoie un Foo, je peux l'utiliser, non ?) ça pète dans les cas où bah… il est pas là ?

                  et en plus faut toujours faire super gaffe parce que tu peux toujours te peter une exception si t’utilise pas orElse()

                  Bon du coup je suis allé vérifier et (modulo une petite touche de verbosité supplémentaire bien Javaesque) ça se comporte comme l'Option de Scala, du coup je comprends pas la remarque. Oui quand tu as "peut-être une String" si tu veux bosser avec une String tout court il faut gérer le cas où elle est pas là…

                  T'es sûr d'avoir bien compris le concept d'un système de type plus avancé ?

                  • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

                    Posté par  . Évalué à 7.

                    C'est quoi ta solution miracle pour représenter "je suis une fonction qui retourne un Foo si ceci et cela, rien si je peux pas", en gardant Foo comme type de retour, mais en évitant qu'en utilisant ce Foo (bah quoi, le type me dit bien que ça renvoie un Foo, je peux l'utiliser, non ?) ça pète dans les cas où bah… il est pas là ?

                    Intégrer l’optionalite/présence garantie au cœur du système de typage. Regarde ce que font swift ou kotlin a ce niveau.

                    T'es sûr d'avoir bien compris le concept d'un système de type plus avancé ?

                    J’ai très bien compris le concept oui.

                    guard let bar: Foo? = myFunctionReturningNullSometimes() else { return }
bar.something() // note que sans le guard, tu peux même pas compiler ce code, le compilo te force à gérer la nullité.
// note aussi la concision. Si tu veux pas return, tu peux faire un if let bar.

                    Face à

                    Optional<Foo> bar = myFunction()
bar.get().something() // et merde ca peut peter, et le compilo ne  me dira rien
// réessayons alors
Foo unwrappedBar = bar.orElse(null); // peut lancer une NPE si je vérifie pas l’implementation de myFunction(), vu que bar lui même peut être null
if (unwrappedBar == null) { return; } // mouais, ben je vois pas vraiment la différence avec juste retourner null, la, tu vois, à part une indirection supplémentaire. Suffit d’un petit refactoring mal placé pour faire disparaître ce if et paf la npe.
unwrappedBar.something()

                    Les typage moderne refusent de compiler du code qui manipule un pointeur qui peut être null.
                    Java détourne le système de typage pour te donner un indice que ce que tu manipule peut être null, ne te donne aucune construction pour t’aider à manipuler le null en question, et le wrapper lui même peut être null. Tout ce que ça fait, c’est ajouter une indirection supplémentaire, sans résoudre le problème de base.

                    Alors tu vas me dire, oui, si ça retourne un optional, par convention, l’optional est garanti non null, sauf qu’au final:

                    • les garanties par convention, c’est mignon, mais ça protège pas des erreurs humaines
                    • optional ne peut qu’indiquer l’optionalite, pas la garantie de presence. Ca sonne con comme ca, mais au final tu sais pas si l’absence d’optional indique la présence garantie, ou si l’auteur de la méthode a juste pas voulu utiliser optional.
                    • le compilo n’a strictement aucun moyen de prouver l’optionalite/présence. C’est très facile de retourner null sur une méthode qui retourne Optional, ou annotée avec @NonNull.
                    • comme indiqué par ckyl, ça marche pas franchement sur des membres, et c’est super bizarre à manipuler sur des paramètres d’entree d’une méthode.

                    Au final, tu te retrouves avec une façon de faire qui n’est appliquable que sur une partie du problème, et qui ne résoud même pas vraiment cette partie du problème. En cadeaux bonux, tu te retrouves aussi avec plus de code, et toujours pas de garantie de pas avoir de npe.
                    Alors, ok, c’est mieux que rien, mais ça reste super bancal.

                    Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                    • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

                      Posté par  . Évalué à 10.

                      Franchement partir sur un troll java dans un journal python… il n'y a que sur DLFP que l'on peut voir ca :D

                    • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

                      Posté par  (site web personnel) . Évalué à 0. 

                      bar.get().something() // et merde ca peut peter, et le compilo ne  me dira rien
// réessayons alors
Foo unwrappedBar = bar.orElse(null); // peut lancer une NPE si je vérifie pas l’implementation de myFunction(), vu que bar lui même peut être null
if (unwrappedBar == null) { return; } // mouais, ben je vois pas vraiment la différence avec juste retourner null, la, tu vois, à part une indirection supplémentaire. Suffit d’un petit refactoring mal placé pour faire disparaître ce if et paf la npe.
unwrappedBar.something()

                      J'espère que c'est un troll parce qu'effectivement si c'est pour écrire ça, tu peux éviter d'utiliser Option/Optional, et quelqu'un qui écrit ça n'a strictement rien compris à la tisane. À bon entendeur si tu étais sérieux…

          • [^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool

            Posté par  . Évalué à 2.

            il suffit de ne pas coder des bugs

            ben oui, bravo, voila la solution, c'est pourtant simple, pourquoi on n'y avait pas pensé avant ?

  • # Les premiers effets...

    Posté par  (Mastodon) . Évalué à 10.

    … de la retraite de Guido se font déja sentir.

    • [^] # Re: Les premiers effets...

      Posté par  . Évalué à 5.

      Pour ceux qui ne suivraient pas, le site ne diffuse que des infos pour de rire

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.