fastcore : réinventer les primitives Python pour les workflows d'IA

L'objectif de fastcore au-delà de fastai

Les métadonnées du dépôt décrivaient initialement fastcore comme un outil destiné à la bibliothèque fastai. Le README clarifiait que le projet s'étend bien au-delà de cet usage. Inspirée par d'autres langages (mixins Ruby, currying Haskell), fastcore cherche à combler les angles morts de la bibliothèque standard Python et à simplifier des tâches répétitives. La version 2, sortie en juillet 2026, marque un tournant : suppression de plusieurs API devenues obsolètes ou remplacées par des alternatives meilleures. Les utilisateurs de `from fastcore.utils import *` restent peu affectés, mais les dépendances directes sur `Param`, `spread` ou `parallel_gen` doivent être migrées. Cette stratégie de nettoyage montre une volonté de maintenir la cohérence plutôt que d'accumuler les APIs dépréciées.

L'ordre de grandeur des structures de données améliorées

La classe L, remplaçante directe de list, représente le cœur de fastcore. L'exemple du README (L(1,2,3,4)) montre l'indexation par collection : x[[0,3]] retourne [1,4] sans boucle explicite. Les chaînes de méthodes se composent naturellement : x.map(lambda o:o*2).filter(lambda o:o>2). Pour la version 2, les méthodes starmap, starfilter sont remplacées par les adaptateurs star() et rstar(), qui composent avec chaque méthode L (par exemple t.map(star(f))). Cette refonte unifie le traitement des fonctions variadiques et élargit les combinaisons possibles. Le README ne chiffre pas les écarts de performance avec une liste standard, mais insiste sur la commodité d'usage : maintien de la sémantique list tout en ajoutant la composition fonctionnelle. Pour les algorithmes sensibles à la latence, une vérification pratique demeure nécessaire.

Le patching de classe sans héritage

Le décorateur @patch permet d'ajouter des méthodes à des classes existantes, y compris les types natifs, sans créer de sous-classe. Python décourage normalement cette pratique, et l'héritage présente des frictions (surcharge d'opérateurs, intégration avec des bibliothèques tierces). fastcore lève cette friction en fournissant un mécanisme natif. Appliqué à la classe Path de pathlib, le patching ajoute des méthodes comme ls(), read_json(), qui allient commodité et cohérence avec le reste de fastcore. Le README n'expose pas les détails : ces méthodes restent-elles visibles en pickle ? Comment interagissent-elles avec le multiprocessing ? L'absence de réponse dans la documentation publique invite à des essais empiriques avant adoption en production.

Initialisation allégée et délégation d'arguments

Le motif classique en Python consiste à écrire `self.x = x`, `self.y = y` et ainsi de suite dans chaque __init__. fastcore introduit store_attr() pour affecter plusieurs attributs en un appel. Le décorateur delegates remplace **kwargs par des paramètres nommés, améliorant l'introspection des IDEs et la génération de documentation. Ces deux outils répondent à des frictions répétitives du Python standard, mais leur interaction avec l'héritage multiple, les annotations de type et les valeurs par défaut demande un apprentissage pratique. Le README énonce le principe sans fournir de gestion des cas complexes ; l'utilisateur doit expérimenter ou consulter les tests du dépôt pour comprendre les limites.

Parallélisation simplifiée et stratégies de test

fastcore fournit des versions améliorées de ThreadPoolExecutor et ProcessPoolExecutor de la bibliothèque standard, avec une API unifiée et des démarrages plus simples. Pour les workflows de parallelisation complexes, la version 2 supprime parallel_gen et recommande le motif `initializer` du ProcessPoolExecutor standard, illustré dans fastai.parallel_tokenize. Les fonctions de test (test_eq, test_ne, test_close) formatent les assertions plus lisiblement et exposent les écarts attendus en cas d'échec. Le README ne détaille pas les gains de performance relatifs ou le format exact des messages d'erreur ; ces aspects doivent être validés par des benchmarks ou l'inspection du code source.

Licence Apache-2.0 et impact sur l'adoption

fastcore est publié sous Apache-2.0, accordant une licence perpétuelle, mondiale et non exclusive pour reproduire, modifier, afficher et distribuer le logiciel. La licence comprend une clause de brevet : elle s'éteint si le licencié engage une action en contrefaçon de brevet contre le projet. Le texte exclut toute garantie, aucun engagement de support, aucune responsabilité en cas de dommages. Pour les projets commerciaux, cette licence est permissive : elle autorise les logiciels propriétaires construits avec fastcore. Pour les projets soumis à des restrictions de brevet ou de brevets concurrents, la clause de révocation mérite une analyse juridique.

Gestion des migrations de v1 à v2

Juillet 2026 a marqué la publication de v2, avec une série de changements cassants. Param, utilisé pour les scripts CLI, est remplacé par les annotations de type brutes et typing.Annotated. Les méthodes star* et rstar* de L migrent vers des adaptateurs de fonction ; spread devient star, dspread devient dstar. Les utilitaires d'asynchronie (run_sync, iter_sync, ctx_sync) sont déplacés vers fastcore.aio ; Config et ses fonctions associées passent de foundation à xtras. fastcore.net perd ses constructeurs de requête. Le README recommande d'épingler fastcore<2 pour les projets qui dépendent des APIs supprimées, mais il ne fournit pas de guide de migration exhaustif ni de calendrier de support pour les anciennes versions.

Conclusion éditoriale

fastcore s'adresse aux développeurs Python travaillant sur des projets d'apprentissage automatique ou d'analyse de données, particulièrement ceux déjà familiers avec l'écosystème fastai. Avant adoption, vérifiez la compatibilité avec Python 3.11+, testez les migrations de la v2 (suppression de Param, renomage des méthodes star*) et consultez la documentation officielle pour valider les performances en parallélisation.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes