Retour sur la PyConFR 2023

XMCO était présent lors de l’édition française 2023 de la PyConFR, une conférence centrée sur le langage de programmation Python. Cette édition s’est tenue du 16 au 19 février sur le campus de l’université de Bordeaux et comportait 2 jours de sprints de développement suivis de 2 jours de présentations et ateliers. 

Nous allons revenir sur 6 présentations données dans le cadre de cette conférence. 

Nous profitons de cet article pour remercier les conférenciers, l’Association Francophone Python (AFPy) ainsi que toute l’équipe ayant donné vie à cette édition de la PyConFR pour leur travail. 

« Faire du Python professionnel » par Éric Dasse et Dimitri Merejkowsky

La popularité du langage Python s’est fortement accrue au cours des dernières années. Cette adoption massive a probablement été en partie favorisée par la simplicité et la permissivité du langage. 

Ces qualités peuvent néanmoins porter préjudice à la maintenabilité d’un projet sur le long terme. En effet, certaines restrictions imposées par d’autres langages de programmation n’existent pas en Python. 

Certains aspects du langage, comme le typage dynamique ou la possibilité de redéfinir à la volée certains éléments, peuvent complexifier la maintenabilité du code si les développeurs ne se sont pas astreints à une certaine rigueur. Cette permissivité peut vite aboutir à la création de dette technique et freiner la collaboration entre développeurs sur un projet. 

C’est ce constat qui a poussé Éric Dasse et Dimitri Merejkowsky à proposer quelques pratiques visant à cadrer les développements Python, afin d’en améliorer la pérennité. 

Ils préconisent notamment de suivre les principes de clean code, qui regroupent des indications de développement indépendantes du langage utilisé. L’objectif de ces pratiques est de produire du code qui soit facilement lisible et modifiable par d’autres développeurs, en plus de répondre au besoin fonctionnel. 

En Python, les directives communément admises comme principes de rédaction de code dit « Pythonique » sont le Zen of Python (qui définit la philosophie du langage et de son utilisation) et la PEP 8 (qui recense les bonnes pratiques de formatage de code Python). 

Éric et Dimitri ont ainsi proposé plusieurs outils visant à faciliter l’adoption de ces principes :  

  • Black pour le formatage automatique de code ;
  • Flake8 pour l’analyse statique, permettant détecter certaines erreurs ;
  • MyPy pour la vérification de l’adéquation entre les types déclarés sur les paramètres d’une fonction (via les annotations de type) et les types des paramètres effectivement passés lors de l’utilisation de la fonction.

Dans le cadre du développement orienté objet, l’utilisation de design patterns (des architectures techniques reconnues permettant de répondre à des besoins répandus chez les développeurs) peut également constituer un référentiel commun pour les développeurs d’un projet. 

« Fear the mutants. Love the mutants. » par Max Kahan

Comment s’assurer que les tests unitaires que nous écrivons pour valider l’implémentation de notre code dans un projet fonctionnent ? C’est la question à laquelle Max Kahan, développeur Python chez Vonage, a essayé de répondre lors de son intervention à la PyConFR.  

Certes, l’intérêt des tests unitaires n’est plus à prouver, mais ils restent limités, affirme notre intervenant, dès lors que les projets grossissent. Très vite, Max Kahan invalide la solution du code coverage, qui donne le taux de code source exécuté d’un programme quand une suite de test est lancée. Il permet en effet de vérifier que toutes les lignes de notre programme sont bien lues mais cela ne garantit pas que son comportement soit conforme à ce qui est attendu. La qualité des tests n’est pas évaluée.  

C’est tout l’intérêt des tests de mutation. Ces tests consistent à subtilement changer une ligne de notre code pour vérifier si cette légère modification, aussi appelée mutation, va empêcher notre code de s’exécuter. Pour reprendre un exemple de mutation qui nous a été donné, une mutation peut consister à changer un opérateur de comparaison dans une valeur retournée par une fonction.

De return age > 18, on passe à return age <= 18.  

Si la mutation n’empêche pas l’exécution complète du programme, cela signifie que les tests n’ont pas été assez spécifiques et qu’il faut donc les améliorer.  

« Python moderne et fonctionnel pour des logiciels robustes » par Guillaume Desforges

Dans cette conférence, Guillaume Desforges, software engineer chez Tweeg, nous présente plusieurs concepts de programmation fonctionnelle et l’apport que ceux-ci peuvent avoir appliqués au développement Python. 

Dans un premier temps, le concept de fonction pures / impures est présenté : une fonction est dite “pure” si elle est totalement déterministe et n’introduit pas d’effet de bords, c’est à dire que les sorties sont toujours les mêmes pour des entrées similaires et que la fonction modifie uniquement son environnement local. Penser son code en termes de fonctions pures et impures permet de découpler les différentes opérations à réaliser, d’externaliser les dépendances et amène naturellement vers une architecture plus robuste : l’architecture en oignon.  

Dans un second temps, on nous présente l’intérêt d’utiliser autant que possible des objets immutables. L’utilisation d’objets mutables doit être un choix conscient et nécessaire, car cela introduit une variabilité qui, dans une architecture complexe, peut facilement être génératrice de bugs. Plusieurs options sont disponibles pour rendre les objets immutables : utiliser l’argument frozen lors de la création d’une dataclass, utiliser un système de properties lors de la création d’une classe ou tout simplement travailler sur une copie des objets avec deepcopy.  

Le dernier point abordé est celui des types : bien qu’étant un langage fortement typé, Python n’a nativement pas d’indication ou de vérification de types à l’écriture. Néanmoins, avoir un typage clair et précis permet non seulement d’améliorer la lisibilité du code mais également d’éviter l’introduction de bugs. Le module typing de la librairie standard Python permet au développeur de spécifier des indications de types à l’écriture mais il existe des modules plus puissants permettant d’effectuer une vérification statique des types comme mypy ou pyright

« Giving and Receiving Great Feedback through PRs » par David Andersson

La revue de code peut devenir un moment de stress, pour le développeur comme pour le relecteur. Plusieurs facteurs, comme la distance géographique entre les équipes ou la difficulté accrue à saisir l’intention derrière un message écrit, peuvent expliquer ce constat. 

Pour éviter cela, David Andersson nous donne plusieurs conseils sur l’attitude à adopter lors de la revue de code. 

Il a commencé par rappeler que l’objectif de la revue de code était de pérenniser le projet en convergeant vers un code respectant les standards de qualité attendus. 

Pour cela, il convient pour le relecteur de communiquer explicitement les raisons justifiant un commentaire sur le code. Prenons l’exemple d’une suite d’opérations réalisant une tâche d’une manière non optimale, entraînant des problématiques de performances. Le commentaire devrait préciser l’impact sur les performances de la solution implémentée, et non pas uniquement inviter le développeur à adopter une autre stratégie. 

Un point complémentaire consiste à garder l’esprit ouvert lors de la relecture. 

En effet, la relecture de code produit par un développeur ne donne pas nécessairement d’indications à propos des raisons l’ayant poussé vers un choix d’implémentation plutôt qu’un autre. Il est donc tout à fait possible qu’un tel choix soit motivé par des raisons légitimes, même si le code semble sujet à discussion au relecteur. Voilà pourquoi ce dernier devrait poser des questions concernant les choix d’implémentation sur lesquels il a un doute, ainsi que suggérer une évolution en consultant l’opinion du développeur plutôt que de l’imposer. 

Cette démarche collaborative peut aboutir à des échanges au cours desquels le développeur et le relecteur ne tomberont pas d’accord. 

Pour David, il est alors important que les deux parties conservent leur calme et continuent de prendre en compte les arguments exposés : la relecture doit porter sur le code et non sur son auteur. 

Enfin, il est conseillé de ne pas sous-estimer l’importance des retours positifs, qui contribuent à l’identification des bonnes pratiques par le développeur tout en atténuant le risque qu’il se sente assailli de retours négatifs, ce qui peut avoir un impact sur son bien-être et entraîner son désengagement du projet. 

« Apport du langage Python dans un service de recherche hospitalière pour mener des analyses de Deep Learning » par Clément Benoist 

Avec l’émergence des Intelligences Artificielles (IA) conversationnelles comme ChatGPT ou Midjourney, l’IA n’a jamais autant été d’actualité et a naturellement fait l’objet de plusieurs conférences lors de la PyConFR. Clément Benoist, chercheur au CHU de Limoges, nous a présenté comment l’IA, et plus particulièrement le Deep Learning, pourrait permettre de résoudre des problématiques médicales. Il revient d’abord sur le choix de son équipe d’avoir opté pour le langage Python, assez rarement utilisé dans les services hospitaliers préférant des langages centrés sur les statistiques et la science des données comme le langage R. Python a été jugé plus performant pour faire du Deep Learning, reposant sur une communauté très active et très populaire, “il parle à tout le monde”.  

La problématique métier à laquelle leur travail répond est la suivante : un patient ayant un rein défaillant peut bénéficier d’une greffe, mais comment s’assurer que celle-ci soit un succès ? Quoiqu’optimale par rapport aux dialyses, cette opération peut entraîner une réaction immunitaire telle que le greffon est rejeté par l’organisme. Au cours de leurs études, ils se sont rendus compte qu’une seule analyse suivie de 3h du patient après sa greffe peut prévenir de la défaillance du greffon, permettant ainsi d’alerter les médecins et les inciter à raccourci le temps entre les séances.  

L’utilisation du Deep Learning reste cependant encore limitée dans le domaine médical. D’une part, elle ne peut pour l’instant qu’être utilisée pour renforcer le suivi d’un patient et non pour le limiter, les conséquences en cas d’erreur pouvant être mortelles. D’autre part, elle nécessite d’avoir accès à des technologies pouvant supporter des calculs puissants, dont les services hospitaliers sont rarement pourvus. Clément Benoist reste optimiste sur l’utilisation de ce type de travaux dans le secteur, et espère pouvoir accéder à des données bien plus volumineuses, dont celle de la Sécurité Sociale, pour optimiser la performance des modèles du Deep Learning.

« pip install malware » par Max Kahan

Après avoir lancé la commande pip install requessts, le package requessts va être automatiquement installé pour peu qu’il soit enregistré dans le Python Package Index PyPi (le dépôt officiel pour télécharger des paquets python). Pourtant ici, l’utilisateur a rajouté un “s” au célèbre package requests compromettant potentiellement sa machine avec un malware.  

Ce sont les risques liés à ce genre d’attaques sur les utilisateurs de PyPi, dites de typosquatting, que nous présente Max Kahan lors de cette conférence. 

Le typosquatting consiste à profiter d’une faute de frappe, d’orthographe ou tout simplement d’un nom ressemblant pour faire passer un package pour un autre. Comme il n’y a pas de contrôle de fichiers lors du dépôt d’un package sur PyPi, il est aisé pour un attaquant de typosquatter des packages populaires. On estime qu’actuellement environ 3% des packages présents sur PyPi et 0.5% de ceux téléchargés chaque jour seraient malveillants. 

En effet, les développeurs sont des cibles très intéressantes : en plus du vol d’identifiants ou l’installation de ransomware, l’attaquant peut cibler les utilisateurs du logiciel développé à partir du package compromis. Dans ce dernier cas, le package malveillant peut fonctionner tout à fait normalement en apparence, rendant très difficile la détection de l’attaque. 

Bien que PyPi supprime régulièrement des packages compromis, il existe différentes méthodes permettant de prévenir ces attaques. Il faut privilégier les fichiers de type requirements.txt plutôt que de taper directement le package à installer, réduisant ainsi le risque d’erreur. Des outils d’analyse automatisés peuvent aussi être utilisés pour valider les dépendances. Enfin les mainteneurs de packages peuvent utiliser des méthodes de typosquatting défensives (c’est à dire enregistrer plusieurs versions du paquet légitime sous les différents noms pouvant être saisis par erreur) pour protéger les utilisateurs de leurs packages. 

Conclusion

En résumé, cette édition de la PyConFR a permis de se familiariser avec des sujets variés. La durée des présentations (30 minutes ou 1 heure) ne permet pas forcément d’aborder les sujets en profondeur, mais offre un panorama intéressant et accessible de ce qui peut être fait avec le langage. 

Ainsi, les Pythonistas et les curieux peuvent tout à fait trouver des sujets susceptibles de les intéresser lors de cette conférence. L’évènement permet d’échanger avec des personnes ayant un bagage technique différent, ce qui est très enrichissant. 

Les vidéos des présentations n’ont pas été mises en ligne au moment où nous écrivions ces lignes. 

Article rédigé en collaboration avec Jonathan Thirion et Antoine Rigoureau.

Experts XMCO

Découvrir d'autres articles

  • Conférences

    Retour sur WestDataFestival 2024

    Lire l'article
  • Conférences

    DORA et la résilience opérationnelle des fournisseurs

    Lire l'article
  • Conférences

    Retour sur la Black Hat Europe 2023

    Lire l'article