Journal PyParis 2018, c'était bien!

Posté par (page perso) . Licence CC by-sa.
Tags :
29
22
nov.
2018

PyParis, c'est un évènement Python annuel sur Paris pendant deux jours. Stéphane Fermigier en avait fait la publicité ici-même. J'en avait profité pour proposer un sujet de conférence qui a été accepté. A ma grande joie!

Mon sujet, c'était l'annotation de type sous Python. Visiblement, mon intervention a bien marché puisque plusieurs personnes sont venues me voir après pour me dire que je les avais convaincu et qu'ils allaient motivier leurs équipes pour passer aux annotations. Si vous voulez savoir pourquoi c'est génial, le mieux est d'aller voir mon intervention sur le site de PyParis, la plupart des vidéos sont maintenant en ligne.

Je n'étais pas le seul lecteur de LinuxFR puisque j'ai assisté à une conférence de Serge-sans-paille qui parlait des échanges entre le code natif et le code Python, tout en essayant de ne pas parler de PyThran.

J'ai beaucoup aimé la conférence en général. En dehors d'une intervention qui était moyenne, toutes les autres étaient passionnantes et j'ai appris plein de trucs. Ça tournait pas mal autour du machine-learning mais pas que. Je crois que nous étions autour de 300 personnes, avec une quinzaine de nationalités représentées.

Ce que je retiens:

  • GraphQL a l'air très bien pour simplifier les architectures REST. Je ne fais ni l'un ni l'autre mais c'est bon à savoir.
  • comment construire un datacenter à prix agressif avec des serveurs recyclés de chez Facebook…
  • classer 250 millions de photos d’hôtel pour que les meilleures apparaissent quand on cherche un hôtel, c'est pas simple mais ça se fait.
  • battre Google sur le prix à mettre pour une campagne de pub, c'est possible
  • faire du Python et de la physique fondamentale peut vous permettre de bosser chez Ubisoft
  • sur le machine learning qui est un sujet auquel je ne connaissais rien, je retiens particulièrement:
    • ca demande des maths, des outils spécifiques et des connaissances théoriques. On s'y met pas en 15 jours comme un nouveau langage de programmation
    • le besoin en puissance de calcul est phénoménal. Du coup, beaucoup d'algorithmes théoriques qui sont très bons mais très consommateurs de CPU/temps ne sont pas utilisés car pas utilisables sur du big data.
    • il faut vraiment pas mal de tuning sur les algos d'apprentissages avant d'arriver à un résultat qui se tient. Ca reste expérimental.

J'ai croisé des gens très sympas et d'un niveau technique très pointu. Ca fait du bien.

J'ai prévu de regarder les vidéos des conférences que j'ai raté, je suis sûr que j'ai encore plein de choses à apprendre.

Et je sais déjà que je reviendrai l'année prochaine !

  • # Les annotations

    Posté par . Évalué à 1.

    Merci pour la partage, je suis incapable de comprendre correctement l'anglais oral, mais les fichiers pdf me suffisent.

    Autant j'utilise de temps en temps les annotations, autant je n'aime guère ce système d'annotations complexes qui rend le code python « moche », de plus cela implique d'importer des modules uniquement pour implémenter ces annotations complexes, parfois même le module root (aucun import de celui-ci dans l'application), alors pour ma part j'en reste aux annotations simples avec les types de bases, et quand le type n'est pas connu dans un module, j'utilise simplement object. En revanche les docstrings de mes classes, méthodes, fonctions renseignent bien à quoi correspondent les paramètres à fournir, sans doute pas suffisant pour les psychos_types_rigides, mais en regard de la philosophie de python, cela l'est bien assez.

    Si déjà tout le monde renseignait correctement les docstrings des applications qu'ils développent, on aura fait un grand pas.

    • [^] # Re: Les annotations

      Posté par (page perso) . Évalué à 3. Dernière modification le 26/11/18 à 12:17.

      C'est vrai que c'est pénible de devoir importer des modules juste pour avoir sous la main la classe pour l'annotation. La première fois que je l'ai fait, ça m'a fait un import circulaire, j'ai cru que j'allais m'arracher les cheveux !

      Je te rejoins aussi sur le fait que ça surcharge pas mal les entêtes de fonctions, qui étaient plus facile à lire sans, surtout quand tu as des valeurs par défaut.

      Cela dit, malgré ces deux inconvénients, je suis très content de les utiliser. Dès que la base de code grossit, qu'il y a plusieurs développeurs dans l'équipe, dès que le projet prend de l'age, les annotations créent beaucoup de valeur car elles vérifient la cohérence globale de ton programme. Ce que ne font pas les docstring.

      Les docstrings ont d'autres inconvénients:
      - parfois, elles sont pas là
      - parfois, elles sont pas assez précises (elles oublient de préciser le type de retour, …)
      - parfois, la fonction a évolué mais le développeur pressé a oublié de la mettre à jour

      Mais surtout:
      - les docstrings ne vérifient pas le type des données avec lesquelles la fonction est appelée
      - les docstrings peuvent contenir une erreur, genre elles disent qu'on peut passer une liste ou un tuple mais en fait, seule une liste fonctionne.

      Comme j'essaie de le montrer dans la présentation, les annotations permettent d’attraper pas mal d'erreur et obligent à clarifie son intention.

Suivre le flux des commentaires

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