Si vous avez lu l’un de mes articles précédents, vous savez que j’aime programmer dans plusieurs langages différents, dont certains me plaisent plus que d’autres. Parfois, un problème nécessite l’utilisation d’une langue particulière, ce qui implique d’adapter son cerveau à la pensée dans cette langue et d’utiliser les idiomes appropriés pour exploiter les caractéristiques de cette langue. Mais que se passe-t-il si je ne veux pas ?
je ne veux pas
La frontière entre R et Python a été très floue ces dernières années, en particulier avec {reticulate} nous permettant d’utiliser Python dans le code R, RStudio rebaptisé Posit et prenant un fort effort de développement Python, publiant Positron en tant qu’IDE multilingue et Quarto étant une refonte multilingue de Rmarkdown.
Je de temps en temps besoin utiliser Python directement – un SDK encapsulant une API existe et je ne veux pas particulièrement passer beaucoup de temps à écrire ma propre version R, surtout avant de savoir ce que je veux retirer des points de terminaison. À ce stade, j’ai tendance à me heurter à ma mémoire musculaire de R et à essayer d’utiliser des fonctions que je connais bien de R, mais qui n’existent pas réellement en Python. Maintenant, cela peut parfois être dû au fait que le modèle que j’essaie d’encoder a simplement un nom différent en Python ; au lieu d’un sapply(x, f)
sapply(c(2, 3, 4, 5), \(x) x ^ 2) ## [1] 4 9 16 25
Je devrais atteindre mapauquel cas je me rappelle que cela produit un itérateur paresseux qui ne me montre pas les résultats
map(lambda x: x ** 2, [2, 3, 4, 5]) ## <map object at 0x10d7fbee0>
et je dois donc l’envelopper dans une liste pour extraire les valeurs
list(map(lambda x: x ** 2, [2, 3, 4, 5])) ## [4, 9, 16, 25]
Ou, je pourrais utiliser une compréhension de liste qui n’est-ce pas paresseux
[v ** 2 for v in [2, 3, 4, 5]] ## [4, 9, 16, 25]
C’est le idiome que je devrais atteindre. Bien sûr.
D’autres fois, je dois utiliser un package et une manière légèrement différente d’aborder le problème. Dans RI j’adore le table() fonction pour obtenir un décompte de type histogramme des valeurs uniques d’un vecteur
table(c("b", "a", "c", "a", "b", "a"))
##
## a b c
## 3 2 1
ce qui en Python ressemble à
from collections import Counter
sorted(Counter(["b", "a", "c", "a", "b", "a"]).items())
## [('a', 3), ('b', 2), ('c', 1)]
Les pythonistes se souviennent probablement de cet idiome, du package à importer et du
.items() extracteur et le fait qu’ils veulent peut-être trier le résultat. Mais je revenais sans cesse à une question que je me pose : et si je ne veux pas? Pourquoi n’y a-t-il pas de fonction qui enveloppe cet idiome ? Si c’était le cas, pourquoi ne pas simplement l’appeler « table » ? Certes, c’est loin d’être le nom le plus accrocheur, le plus mémorable ou le plus utile, mais il est immédiatement reconnaissable pour un utilisateur R (idem pour « sapply »).
Une approche que j’ai envisagée ici consistait simplement à appeler R depuis Python. Que peut être fait, mais je doute que moi ou quelqu’un d’autre veuille gérer cela à chaque fois que nous voulons parcourir une liste. Il existe un package sur l’index du package Python qui semble bien prendre en charge cela : mais il s’agit de wrappers autour de fichiers R individuels, via RScript. Je pense davantage à «Python natif avec une interface R».
Python est un langage orienté objet, mais il a fonctions, alors pourquoi ne pas en créer une
from collections import Counter
def table(x):
return dict(sorted(Counter(x).items()))
table(["b", "a", "c", "a", "b", "a"])
## {'a': 3, 'b': 2, 'c': 1}
def sapply(x, func):
return [func(v) for v in x]
sapply([2, 3, 4, 5], lambda x: x ** 2)
## [4, 9, 16, 25]
et avoir une interface de fonction plus agréable pour appliquer ces idiomes ? J’y ai réfléchi un peu plus longtemps et j’ai réalisé qu’il y avait beaucoup de fonctions que j’utilise dans R et que j’aimerais pouvoir utiliser en Python. Un idiome pour trouver l’index des éléments d’un « vecteur » (liste en Python) qui sont vrais (TRUE dans R, True en Python) est
[i for i, v in enumerate(x) if v]
mais je veux juste appeler which(x)
which(c(FALSE, FALSE, TRUE, FALSE , TRUE)) ## [1] 3 5
alors pourquoi ne pas définir cela
def which(x):
return [i for i, v in enumerate(x) if v]
which([False, False, True, False, True])
## [2, 4]
(en rappelant que Python est indexé 0).
Jusqu’où peut-on aller dans ce sens ? Un chemin assez long !
J’ai réfléchi davantage aux différences qu’il faudrait prendre en compte, et celle qui m’est immédiatement venue à l’esprit était que R est vectorisé. Si je devais recréer la fonction de comptage de caractères de R nchar(s) comme essentiellement len(s)je devrais me demander si je voulais que cela fonctionne sur une seule chaîne ou sur un « vecteur » de chaînes
Dans R :
nchar(c("these", "all", "have", "different", "lengths"))
## [1] 5 3 4 9 7
Mais en Python, len() attend une seule valeur, il calcule donc la longueur de la liste
len(["these", "all", "have", "different", "lengths"]) ## 5
La « bonne » façon de procéder est de cartographier la liste
[len(s) for s in ["these", "all", "have", "different", "lengths"]] ## [5, 3, 4, 9, 7]
mais encore une fois, pourquoi dois-je utiliser un idiome pour cela ? Et si je venais de demander à un décorateur de changer une fonction régulière en une fonction vectorisée en appliquant cette compréhension de liste en interne lorsqu’il lui transmet une liste (ou un tuple), et qui autrement évalue simplement la fonction avec l’argument ?
import functools
def make_vec(func):
@functools.wraps(func)
def wrapper(*args, **kwargs):
if isinstance(args[0], (list, tuple)):
return [func(xi, *args[1:], **kwargs) for xi in args[0]]
return func(*args, **kwargs)
return wrapper
@make_vec
def my_len(s):
return len(s)
my_len(["these", "all", "have", "different", "lengths"])
## [5, 3, 4, 9, 7]
et je pourrais l’appeler… « nchar » !
L’autre cas d’utilisation qui m’est venu à l’esprit était qu’Elio expliquait (et faisait référence à un article auquel j’avais également écrit une sorte de réponse) dont ils avaient besoin pour lister les fichiers dans le répertoire actuel.
avec l’idiome
import os [os.path.join(path, f) for f in os.listdir(path)]
Les suggestions fournies incluses
from pathlib import Path list(Path(path).iterdir())
(ça sort de la langue, n’est-ce pas ?) qui renvoie une liste de PosixPath()
objets et est difficilement facile à analyser visuellement.
Alors pourquoi ne pas avoir une fonction ?!?
import os
def list_files(path):
return [os.path.join(path, f) for f in os.listdir(path)]
path = "path/to/files"
list_files(path)
## ['path/to/files/file1.txt', 'path/to/files/file2.txt', 'path/to/files/file3.csv']
J’aurais aimé appeler ça list.files() mais, puisque Python utilise strictement le point pour l’appel de méthode, cela ne peut pas être le cas.
Cela soulève alors la question « dois-je prendre en charge les arguments déjà présents dans les fonctions R ? » Dans ce cas, devrait-il prendre en charge un recursive argument? Oui, cela ajoute de la complexité, mais c’est sûrement faisable. À ce stade, j’ai demandé l’aide de l’IA et j’ai demandé à Claude de m’aider à mettre en œuvre autant de fonctions que possible, en soutenant autant d’arguments communs que possible. Cela impliquait d’étendre le décorateur pour prendre en charge la vectorisation d’autres arguments (qui doivent également faire attention aux points).
En le testant, il semblait que nous avions quelque chose de viable.
Il y a cependant un dernier élément que je voulais soutenir : le which() l’exemple ci-dessus extrait les éléments d’un logique vecteur qui sont Truemais pour construire ce vecteur en premier lieu, j’utiliserais naturellement la vectorisation de R en tant que langage de tableau. Les deux étapes impliquées ici consistent d’abord à calculer la comparaison résultant en un vecteur logique, puis à utiliser which() identifier les indices de ceux qui sont vrais
which(c("c", "b", "a", "c", "a", "b") == "a")
## [1] 3 5
Le décorateur de vectorisation ci-dessus n’aide pas ici, car il est au point de
== que l’on veut vectoriser
['c', 'b', 'a', 'c', 'a', 'b'] == 'a' ## False
C’est False parce que le personnage 'a' n’est pas égal à la liste donnée.
L’expression appropriée est encore une fois d’utiliser une compréhension de liste
which(x == 'a' for x in ['c', 'b', 'a', 'c', 'a', 'b']) ## [2, 4]
La solution que j’aime est de créer une nouvelle classe ‘Vec’ qui enveloppe les opérateurs binaires avec une compréhension de liste, en faisant encore une fois abstraction de ce détail. Cela signifie mettre en œuvre __eq__, __add__, __and__ et plein d’autres opérations binaires, mais avec ça, et un wrapper pour créer un tel objet, les opérateurs de comparaison peuvent être vectorisés
vals = vec(['c', 'b', 'a', 'c', 'a', 'b']) which(vals == 'a') ## [2, 4]
Pas vierge, mais plutôt propre, à mon avis.
Avec tous ces éléments en place, en ajoutant des implémentations pour les fonctions de base communes de R, y compris la plupart des arguments et un moyen de vectoriser des listes, j’ai tout enveloppé dans un package Python (mon premier) pour apprendre comment le faire.
Le flux de travail n’est pas particulièrement pénible, ma plus grande complication étant les différentes versions de Python prenant en charge différentes exigences dans pyproject.tomlet donc certaines actions GitHub échouent à cause de cela.
Dans le cadre de la construction des implémentations, j’ai demandé à Claude d’ajouter des tests pour chacune des fonctions avec certaines valeurs attendues – si je faire Je veux améliorer certains idiomes en interne, je veux m’assurer de ne pas modifier les valeurs produites. Cela fonctionne pour n’importe quel test, mais comment puis-je être sûr que je reproduis ce que j’obtiendrais si je travaillais dans R ? Une option consistait simplement à exécuter toutes les fonctions de test à la main et à confirmer que les valeurs étaient suffisamment similaires, en tenant compte de l’indexation liste/vecteur et 0/1. Au lieu de cela, Claude a réussi à écrire un adaptateur pour pytest qui fait le réalignement de par exemple list_files à list.files
(et de même pour les arguments), réaligne l’indexation si nécessaire et exécute tous les tests existants directement dans R via rpy2 (en sautant certains pour lesquels je n’ai pas encore de tests). Je désactive les tests automatisés car je soupçonne que cela pourrait devenir instable avec R et Python sur GitHub Actions, mais je peux confirmer que tous les tests actuels réussissent.
Je voulais avoir un site Web de documentation similaire à celui que nous avons via {pkgdown} et je suis tombé sur quartodoc, qui est utilisé par la version Python de {pins}. Pour que cela fonctionne, il fallait rétrograder une dépendance Python spécifique, mais cela était par ailleurs indolore.
J’ai un package fonctionnel localement – comment puis-je le partager ? Cela semblait être l’occasion idéale d’apprendre à quoi ressemble le processus de publication de Python. J’ai une poignée de packages sur CRAN et un sur Bioconductor, et le processus est loin d’être fluide, avec pour effet secondaire que vous pouvez accorder une certaine confiance à l’interopérabilité des packages et à une vérification de code minimale (automatisée). Bien que Python soit plus « sauvage » en termes de ce qui peut être téléchargé, c’est vraiment agréable de voir qu’ils disposent d’un serveur de test entièrement séparé sur lequel vous pouvez télécharger votre package et voir à quoi il ressemble. Je me souviens de la citation
Tout le monde a un environnement de test. Certaines personnes ont la chance de disposer d’un environnement totalement séparé pour exécuter leur production.
Étant donné qu’il n’est actuellement pas possible d’exécuter 100 % des contrôles CRAN localement (et même certains que vous peut donnent un résultat différent à ce qui se trouve sur leurs systèmes), cela me rend un peu jaloux. Je me demande si la diminution de la charge due au rejet des soumissions défaillantes compenserait la prise en charge d’un serveur de soumission de tests.
Tout s’est bien passé en poussant vers le serveur de test (via une clé d’authentification) et j’ai réussi à avoir le courage de pousser vers l’instance de production… c’est en direct !
logo rfuns – Les fonctions R en Python… sont amusantes
et le site de documentation n’est pas trop mal non plus (à mon avis).
Cela signifie que vous pouvez maintenant exécuter
uv add rfuns
(ou l’équivalent dans n’importe quelle configuration de gestion d’environnement virtuel que vous utilisez, par exemple pip install rfuns) et commencez à utiliser certaines fonctions R directement en Python !
Selon la manière dont vous souhaitez gérer vos importations, vous pouvez tout importer
from rfuns import * which([False, False, True, False, True]) ## [2, 4]
ou, si vous préférez l’espace de noms
import rfuns as r r.which([False, False, True, False, True]) ## [2, 4]
La liste des fonctions actuellement importées, regroupées en sections, est la suivante :
Cordes
nchar(x)nzchar(x)paste(*args, sep=" ", collapse=None)paste0(*args, collapse=None)grepl(pattern, x, ignore_case=False, fixed=False)grep(pattern, x, ignore_case=False, fixed=False, value=False, invert=False)gsub(pattern, replacement, x, ignore_case=False, fixed=False)sub(pattern, replacement, x, ignore_case=False, fixed=False)trimws(x, which="both", whitespace=r"[ \t\r\n]")toupper(x)tolower(x)startsWith(x, prefix)endsWith(x, suffix)strsplit(x, split, fixed=False)substr(x, start, stop)chartr(old, new, x)formatC(x, digits=6, format="g", width=None)
Vecteurs
which(x)which_min(x)which_max(x)diff(x, lag=1)cumsum(x)cumprod(x)cummax(x)cummin(x)rev(x)duplicated(x)setdiff(x, y)intersect(x, y)union(x, y)unique(x)seq_along(x)seq_len(n)seq(from_=0, to=None, by=None, length_out=None)(fromest un mot clé réservé)sign(x)r_range(x)(renommé pour ne pas entrer en conflit avecrange())
Mathématiques
sign(x)trunc(x)ceiling(x)floor(x)sqrt(x)log(x, base=None)log2(x)log10(x)exp(x)abs(x)var(x, na_rm=False)sd(x, na_rm=False)mean(x, na_rm=False)median(x, na_rm=False)quantile(x, probs=None, na_rm=False)scale(x, center=True, scale_=True)round(x, digits=0)
Fichiers
list_files(path=".", pattern=None, all_files=False, full_names=False, recursive=False, ignore_case=False, include_dirs=False, no_dot=False)file_exists(path)dir_exists(path)basename(path)dirname(path)file_path(*args)
Tableau
table(x)prop_table(x)margin_table(x)
Fonctionnel
lapply(x, func)sapply(x, func)vapply(x, func, expected_type)tapply(x, index, func)rapply(x, func)Filter(func, x)Map(func, *args)Reduce(func, x, init=None, accumulate=False)
Inspecter
head(x, n=6)tail(x, n=6)length(x)nrow(x)ncol(x)dim(x)summary(x)rstr(x)(renommé pour ne pas entrer en conflit avecstr())
Utilitaires
Certains d’entre eux sont vectorisés
nchar(["these", "all", "have", "different", "lengths"])
## [5, 3, 4, 9, 7]
grepl("ar", ["frog", "carpet", "basket", "dart"])
## [False, True, False, True]
sqrt([36, 81, 9])
## [6.0, 9.0, 3.0]
tandis que d’autres (approximativement, jusqu’à l’indexation 0) préservent le comportement R, comme comment seq() travaux
seq(5) ## [0, 1, 2, 3, 4] seq(from_=0, to=10, by=2) ## [0, 2, 4, 6, 8, 10]
(noter que from est un mot-clé en Python, donc l’argument ici est maintenant from_) et définir les opérations
setdiff([5, 2, 4, 1], [2, 1]) ## [5, 4]
alors que cela ne préserve pas l’ordre
set([5, 2, 4, 1]) - set([2, 1])
## {4, 5}
Faire tous cela aurait pris moi-même un certain temps, je suis donc reconnaissant de pouvoir diriger un agent vers l’accomplissement de certaines des parties fastidieuses de ce projet. J’ai toujours piloté la prise de décision et veillé à vérifier les résultats, donc je ne considère pas cela comme un projet « codé en ambiance ».
Je ne vous recommande pas du tout de l’utiliser en production – j’ai pris n’importe quel idiome que je pouvais trouver (ou générer) pour les composants internes de tout cela, et je n’ai prêté aucune attention à leurs performances. L’objectif était de me permettre de travailler plus facilement de manière interactive dans un REPL lorsque j’utilise des fonctions particulières. Cela étant dit, je ferai volontiers de mon mieux pour comprendre les versions Pythonic du mieux que je peux afin de pouvoir mieux apprécier Python natif et utiliser les idiomes lorsque mon package d’assistance n’est pas disponible (ou inadapté). Je dirais qu’il est juste de dire que les utilisateurs de R utilisant Python devrait apprendre à faire les choses de manière pythonique, mais je veux aussi juste faire quelques petites choses de temps en temps, donc je suis heureux que cela existe maintenant.
Si vous travaillez avec des collègues non-R, l’introduction de ces abstractions – même si elles peuvent vous simplifier la vie sur le moment – entraînera probablement de la confusion car vous cacherez l’implémentation et lui donnerez un nom qu’ils ne reconnaîtront pas. C’est précisément à cela que servent les fonctions (avec des noms utiles), bien sûr, mais à moins que ce package ne devienne populaire, je parie que les idiomes en ligne sont plus bienvenus dans une base de code.
J’aimerais entendre ce que les gens en pensent, même si je suis tout à fait d’accord avec le fait d’en être le seul utilisateur. Dois-je simplement forcer ma mémoire musculaire à adopter les idiomes Python ? Vais-je être puni pour avoir « traversé les courants » de deux langues incompatibles ? Est-ce que cela vous serait utile ? Y a-t-il d’autres considérations que j’ai manquées ? Comme toujours, je peux être trouvé sur Mastodon et dans la section commentaires ci-dessous.
Merci à Elio Campitelli et Michael Sumner pour leurs commentaires sur une ébauche de cet article.
devtools :: session_info ()
## ─ Session info ─────────────────────────────────────────────────────────────── ## setting value ## version R version 4.5.3 (2026-03-11) ## os macOS Tahoe 26.3.1 ## system aarch64, darwin20 ## ui X11 ## language (EN) ## collate en_US.UTF-8 ## ctype en_US.UTF-8 ## tz Australia/Adelaide ## date 2026-05-22 ## pandoc 3.6.3 @ /Applications/RStudio.app/Contents/Resources/app/quarto/bin/tools/aarch64/ (via rmarkdown) ## quarto 1.7.31 @ /usr/local/bin/quarto ## ## ─ Packages ─────────────────────────────────────────────────────────────────── ## package * version date (UTC) lib source ## blogdown 1.23 2026-01-18 [1] CRAN (R 4.5.2) ## bookdown 0.46 2025-12-05 [1] CRAN (R 4.5.2) ## bslib 0.10.0 2026-01-26 [1] CRAN (R 4.5.2) ## cachem 1.1.0 2024-05-16 [1] CRAN (R 4.5.0) ## cli 3.6.5 2025-04-23 [1] CRAN (R 4.5.0) ## devtools 2.4.6 2025-10-03 [1] CRAN (R 4.5.0) ## digest 0.6.39 2025-11-19 [1] CRAN (R 4.5.2) ## ellipsis 0.3.2 2021-04-29 [1] CRAN (R 4.5.0) ## evaluate 1.0.5 2025-08-27 [1] CRAN (R 4.5.0) ## fastmap 1.2.0 2024-05-15 [1] CRAN (R 4.5.0) ## fs 1.6.7 2026-03-06 [1] CRAN (R 4.5.2) ## glue 1.8.1 2026-04-17 [1] CRAN (R 4.5.2) ## htmltools 0.5.9 2025-12-04 [1] CRAN (R 4.5.2) ## jquerylib 0.1.4 2021-04-26 [1] CRAN (R 4.5.0) ## jsonlite 2.0.0 2025-03-27 [1] CRAN (R 4.5.0) ## knitr 1.51 2025-12-20 [1] CRAN (R 4.5.2) ## lattice 0.22-9 2026-02-09 [1] CRAN (R 4.5.3) ## lifecycle 1.0.5 2026-01-08 [1] CRAN (R 4.5.2) ## magrittr 2.0.4 2025-09-12 [1] CRAN (R 4.5.0) ## Matrix 1.7-4 2025-08-28 [1] CRAN (R 4.5.3) ## memoise 2.0.1 2021-11-26 [1] CRAN (R 4.5.0) ## otel 0.2.0 2025-08-29 [1] CRAN (R 4.5.0) ## pkgbuild 1.4.8 2025-05-26 [1] CRAN (R 4.5.0) ## pkgload 1.5.0 2026-02-03 [1] CRAN (R 4.5.2) ## png 0.1-9 2026-03-15 [1] CRAN (R 4.5.2) ## purrr 1.2.2 2026-04-10 [1] CRAN (R 4.5.2) ## R6 2.6.1 2025-02-15 [1] CRAN (R 4.5.0) ## Rcpp 1.1.1 2026-01-10 [1] CRAN (R 4.5.2) ## remotes 2.5.0 2024-03-17 [1] CRAN (R 4.5.0) ## reticulate 1.45.0 2026-02-13 [1] CRAN (R 4.5.2) ## rlang 1.1.7 2026-01-09 [1] CRAN (R 4.5.2) ## rmarkdown 2.30 2025-09-28 [1] CRAN (R 4.5.0) ## rstudioapi 0.18.0 2026-01-16 [1] CRAN (R 4.5.2) ## sass 0.4.10 2025-04-11 [1] CRAN (R 4.5.0) ## sessioninfo 1.2.3 2025-02-05 [1] CRAN (R 4.5.0) ## usethis 3.2.1 2025-09-06 [1] CRAN (R 4.5.0) ## vctrs 0.7.1 2026-01-23 [1] CRAN (R 4.5.2) ## withr 3.0.2 2024-10-28 [1] CRAN (R 4.5.0) ## xfun 0.56 2026-01-18 [1] CRAN (R 4.5.2) ## yaml 2.3.12 2025-12-10 [1] CRAN (R 4.5.2) ## ## [1] /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/library ## ## ─ Python configuration ─────────────────────────────────────────────────────── ## python: /Users/jono/.cache/uv/archive-v0/Q1veGTfRq3GBaNYBXjagV/bin/python ## libpython: /Users/jono/.local/share/uv/python/cpython-3.12.12-macos-aarch64-none/lib/libpython3.12.dylib ## pythonhome: /Users/jono/.cache/uv/archive-v0/Q1veGTfRq3GBaNYBXjagV:/Users/jono/.cache/uv/archive-v0/Q1veGTfRq3GBaNYBXjagV ## virtualenv: /Users/jono/.cache/uv/archive-v0/Q1veGTfRq3GBaNYBXjagV/bin/activate_this.py ## version: 3.12.12 (main, Oct 28 2025, 11:52:25) [Clang 20.1.4 ] ## numpy: /Users/jono/.cache/uv/archive-v0/Q1veGTfRq3GBaNYBXjagV/lib/python3.12/site-packages/numpy ## numpy_version: 2.4.6 ## ## NOTE: Python version was forced by VIRTUAL_ENV ## ## ──────────────────────────────────────────────────────────────────────────────
En rapport
PakarPBN
A Private Blog Network (PBN) is a collection of websites that are controlled by a single individual or organization and used primarily to build backlinks to a “money site” in order to influence its ranking in search engines such as Google. The core idea behind a PBN is based on the importance of backlinks in Google’s ranking algorithm. Since Google views backlinks as signals of authority and trust, some website owners attempt to artificially create these signals through a controlled network of sites.
In a typical PBN setup, the owner acquires expired or aged domains that already have existing authority, backlinks, and history. These domains are rebuilt with new content and hosted separately, often using different IP addresses, hosting providers, themes, and ownership details to make them appear unrelated. Within the content published on these sites, links are strategically placed that point to the main website the owner wants to rank higher. By doing this, the owner attempts to pass link equity (also known as “link juice”) from the PBN sites to the target website.
The purpose of a PBN is to give the impression that the target website is naturally earning links from multiple independent sources. If done effectively, this can temporarily improve keyword rankings, increase organic visibility, and drive more traffic from search results.
