Pourquoi passer de R à Python ?

Cinq raisons principales amènent à considérer le passage de R à Python :

• les spécificités des langages ;
• l’écosystème dans lequel évolue le langage
• le contexte d’utilisation ;
• les ressources internes (développeurs) ;
• des contraintes d’infrastructure.

Spécificités du langage

La guerre des langages de programmation, à l’instar de celle des éditeurs de textes, est éternelle, en témoignent les classements récurrents qui agitent la toile. Pourtant, il est difficile de décréter qu’un certain langage est intrinsèquement meilleur qu’un autre. En revanche, chaque langage a ses spécificités, ce qui fait qu’il est préférable d’utiliser l’un plutôt que l’autre suivant le contexte d’utilisation.

Dans le cas de Python et R, les deux langages ont globalement les mêmes caractéristiques : ce sont tous deux des langages interprétés, relativement lents, mais qui profitent d’implémentations en langages de plus bas niveau (C++, C, Fortran), tirant parti d’optimisations matérielles le cas échéant. Ainsi, certaines parties sont exécutées en dehors de l’environnement d’exécution du langage, déportées pour tourner plus vite ou occuper moins de mémoire vive. Python et R s’interfacent donc avec des bibliothèques optimisées compilées et offrent à l’utilisateur leur souplesse pour écrire un code lisible et extrêmement concis.

Python et R sont deux langages fortement et dynamiquement typés. Les différences entre ces deux langages en tant que tels sont principalement d’ordre syntaxique. La préférence d’un langage par rapport à l’autre tient alors de deux autres aspects importants : l’écosystème et les goûts de l’utilisateur.

Écosystème

Chaque langage propose des fonctionnalités qui sont incluses dans le langage lui-même, ou dans la bibliothèque standard (partie qui ne fait pas partie du langage lui-même mais qui est installée par défaut avec). Cependant, la grande majorité des fonctionnalités sont implémentées dans des bibliothèques externes qu’il faut installer en complément.

C’est donc souvent dans cet écosystème que résident les différences majeures qui font préférer l’un plutôt que l’autre. De par son historique, Python, étant un langage généraliste, possède davantage de bibliothèques qui concernent le réseau, la création de services web, la gestion des formats de fichiers variés, etc. R, historiquement un langage de statistiques, offre plus de bibliothèques de niches, implémentant de nombreux algorithmes d’articles de recherche.

Contexte de maintenance et développement

Une autre partie de l’écosystème concerne la communauté qui l’utilise : plus ses utilisateurs ont le même profil d’utilisation que nous, plus l’aide et les solutions de résolutions seront faciles à trouver.

Plus encore que l’écosystème, c’est principalement les personnes amenées à travailler sur le projet qui dictent le langage à utiliser : il est préférable d’utiliser un langage que l’on connaît, avec lequel on a acquis une certaine expérience. La connaissance du langage, des bibliothèques principales, de l’environnement de développement (IDE, débugger, framework de test, etc.), l’habitude acquise, etc., sont autant de critères qui poussent à l’adoption d’un langage au détriment d’un autre.

Souvent les équipes chargées de la mise en production et celles de recherche sont différentes, avec des pratiques de développement différentes, et par conséquent… des langages de programmation différents. Il est alors utile de pouvoir faire une transition la plus fluide possible entre les deux langages.

Stratégies pour passer de R à Python

Plusieurs stratégies sont possibles pour une transition fluide de Python à R, celles-ci pouvant être combinées.

Microservices

Une première solution est de faire cohabiter les deux en séparant les fonctionnalités, en formant des microservices différents. Dans un contexte de mise en production, il peut être intéressant de gérer la qualité des données en Python dans un microservice, et d’utiliser un algorithme spécifique d’une bibliothèque disponible seulement en R dans un autre microservice. La communication entre les deux web services peut se faire avec une API HTTP ou bien via des data brokers.

Découpler les fonctionnalités en microservices distincts permet en outre de passer à l’échelle en dupliquant le service qui constitue le goulot d’étranglement.

Appeler un langage de programmation à partir d’un autre

La séparation en microservices distincts nécessite d’établir une API pour communiquer. Elle requiert aussi des compétences dans les composants permettant de l’implémenter. Une autre stratégie pour éviter celà est de passer par une API transparente pour l’utilisateur : les bibliothèques rpy2 et reticulate permettent respectivement d’appeler R à partir de Python et inversement. Les données peuvent être passées de manière transparente entre les deux via un partage de dataframe en mémoire.

Utiliser des packages similaires

Les deux premières stratégies de migration visent à faire cohabiter les deux langages. Pour aller plus loin dans la transition, on peut utiliser en Python des bibliothèques très proches des incontournables ggplot2 et dplyr : plotnine est une implémentation en Python de la « Grammar of Graphics » de Wilkinson, et donc très similaire à la bibliothèque de visualisation ggplot2 de R. dppd et d’autres alternatives proposent des interfaces très similaires à la bibliothèque de manipulation de données dplyr de R.

Ces bibliothèques, parce que très similaires à celles couramment utilisées en R, permettent une transition en douceur. Mais elles demeurent méconnues de celles utilisées majoritairement en Python.

Le grand saut : ce qui change vraiment

Afin d’avoir un code maintenable par des adeptes de Python, une conversion vers les bibliothèques majeures de l’écosystème Python est souvent nécessaire. Les équivalences sont connues : Pandas pour remplacer tibble, tidyr, readr et dplyr ; ou scikit-learn pour se substituer à caret et mlr3 ; ou Plotly pour remplacer… Plotly.

Hormis cette différence d’écosystème, deux points d’attention sont également à considérer :

• les structures de données ;
• l’utilisation des fonctionnalités intégrées au langage plutôt que celles de bibliothèques externes.

Structures de données

Une subtilité peut engendrer des dysfonctionnements majeurs : l’indexation en R commence à 1 tandis que celle de Python commence à 0. Si la couverture des tests unitaires n’est pas suffisante, ce petit changement peut passer inaperçu lors du développement et engendrer des erreurs difficiles à trouver en production.

Une autre différence est l’orientation des données dans les matrices : en R, les données sont ordonnées par colonnes tandis qu’en Python elles sont en lignes par défaut. Voici deux codes qui illustrent cet aspect :

Là encore, ce simple changement d’orientation de matrice peut avoir des impacts conséquents.

Bibliothèque standard et packages externes

Les fonctions de tests statistiques intégrées au langage R sont à trouver en Python dans des packages externes tels que statsmodels. À l’inverse, le système de packaging de Python trouve son semblable dans une bibliothèque externe de R telle que box. C’est d’ailleurs la limitation du système de packaging de R, non hiérarchique, qui fait que les bibliothèques ont tendance à être beaucoup plus ciblées que celles de Python.

D’autres fonctionnalités disponibles dans des modules externes en R sont directement disponibles dans la bibliothèque standard Python (c’est le cas par exemple du package R purrr qui trouve une partie de son équivalent dans le module itertools de la bibliothèque standard Python).

Ces différences impliquent des changements qui sont loin d’être insurmontables mais allongent le temps de développement lié à la transition : la syntaxe et la gestion des dépendances impliquent des adaptations.

Accompagnement

La transition d’un langage à un autre relève d’un choix qui est dirigé par plusieurs considérations : l’écosystème et la composition de l’équipe amenée à travailler et maintenir le projet. Ce choix doit être éclairé car il implique des changements qui méritent l’attention : différences de bibliothèques, spécificités du langage, environnement de développement, etc. Fort de notre expérience dans le développement en Python et en R, Kernix vous accompagne pour choisir la stratégie la plus adaptée à votre besoin et mener à bien la transition.