Python

Un test qui doit isoler une fonction de ses dépendances finit souvent par empiler les patch(). Trois dépendances, trois with imbriqués. Cinq dépendances, une pyramide qui pousse le code utile à dix niveaux d’indentation. Le test devient illisible alors que son intention est simple : vérifier un seul comportement à une frontière précise. contextlib.ExitStack résout exactement ce problème. C’est un gestionnaire de contexte qui en agrège un nombre quelconque d’autres, et les ferme tous proprement à la sortie. Voici comment je m’en sers pour garder un test centré sur sa frontière, avec un cas concret sur l’authentification. ...

Consommer une API externe paraît anodin au premier abord. On fait un requests.get, on récupère un dictionnaire, et on l’utilise tel quel dans le reste du code. Le problème commence quand cette même structure JSON se retrouve disséminée dans dix fichiers, et que l’API change un nom de champ ou passe price de float à string. La correction devient une chasse au trésor. La couche anti-corruption (Anti-Corruption Layer, ou ACL) répond à ce problème. Issue du Domain-Driven Design, elle agit comme un traducteur entre un système externe et votre logique métier. Un seul point de contact, un seul endroit à modifier quand l’API change. ...

Les permissions dans Django REST Framework fonctionnent, mais elles montrent leurs limites dès que les règles d’accès deviennent un peu complexes. Plusieurs rôles, des objets appartenant à un utilisateur, des actions custom sur un ViewSet : on se retrouve rapidement avec des classes has_permission et has_object_permission qui mélangent des vérifications hétérogènes, difficiles à lire et encore plus difficiles à tester. rest_access_policy (paquet djangorestframework-access-policy) propose une autre approche : déclarer les règles d’accès sous forme de statements, à la manière des politiques IAM d’AWS. Le résultat est lisible en un coup d’oeil, testable indépendamment du ViewSet, et extensible sans réécrire toute la classe. ...

Une comparaison == sur un hash ne suffit pas à choisir le bon mécanisme. sha256, HMAC, hash salé, chiffrement : chaque approche offre des garanties différentes. Comprendre lesquelles change concrètement la façon de stocker et vérifier un token en Django. Hash simple import hashlib token_hash = hashlib.sha256(token.encode()).hexdigest() Un hash simple est déterministe : la même entrée produit toujours la même sortie. Aucun secret serveur n’est impliqué. Il est impossible de retrouver le token original depuis le hash (sha256 est une fonction à sens unique). Mais si quelqu’un connaît ou devine le token, il peut recalculer le hash et comparer. ...

Le module collections est dans la bibliothèque standard Python depuis la version 2.4. Il expose des structures de données spécialisées qui résolvent des problèmes récurrents sans dépendance externe. Pourtant, beaucoup de développeurs continuent d’écrire des boucles de comptage, des initialisations conditionnelles de clés, ou des classes Point avec x, y, z alors que Counter, defaultdict et namedtuple font exactement cela, mieux et plus lisiblement. Voici les six structures que j’utilise régulièrement, avec les cas où elles changent vraiment quelque chose. ...

Quand on a besoin de copier un répertoire, déplacer des fichiers ou créer une archive en Python, la tentation est de passer par subprocess.run(["cp", "-r", ...]) ou os.system("mv ..."). C’est fragile, non portable et inutile : shutil (shell utilities) est dans la bibliothèque standard Python depuis la version 2.3 et gère tout cela proprement. La bibliothèque Python shutil est l’outil de référence pour toutes les opérations de haut niveau sur le système de fichiers. ...

La librairie operator fait partie de la bibliothèque standard de Python depuis toujours, et pourtant beaucoup de développeurs continuent d’écrire lambda x: x[0] ou lambda obj: obj.nom quand une fonction de operator ferait le même travail, en plus rapide et plus lisible. Comprendre ce que cette librairie offre, et comment elle est implémentée, change la façon dont on écrit du code fonctionnel en Python. Ce que contient operator operator expose des fonctions qui correspondent aux opérateurs du langage. operator.add(2, 3) est l’équivalent fonctionnel de 2 + 3, operator.lt(a, b) correspond à a < b. L’intérêt n’est pas de remplacer les opérateurs dans du code arithmétique ordinaire, ce serait absurde. L’intérêt est de pouvoir passer une opération comme argument à une fonction d’ordre supérieur (map, filter, sorted, reduce, functools.partial). ...

Les dataclasses Python génèrent automatiquement __init__, __repr__ et __eq__ à partir des annotations de type. Dès qu’un attribut doit avoir une valeur par défaut mutable (liste, dictionnaire, ensemble), on se heurte à un problème fondamental du langage. field(default_factory=...) est la solution, et comprendre pourquoi elle est nécessaire change la façon dont on raisonne sur l’initialisation en Python. Le piège des valeurs mutables par défaut En Python, les valeurs par défaut des paramètres de fonction sont évaluées une seule fois au moment de la définition de la fonction, pas à chaque appel. C’est une propriété du langage, pas un bug. ...

Appeler obj.save() après avoir défini des validators et un clean() sur le modèle laisse croire que la validation est garantie. Elle ne l’est pas. Django ne déclenche pas full_clean() lors d’un save(), et ce comportement est délibéré. Comprendre pourquoi change la façon d’architecturer la validation dans un projet. Ce que save() fait réellement Le cycle de vie d’un save() est plus court que ce qu’on imagine : Signal pre_save envoyé field.pre_save() appelé sur chaque champ (auto_now, auto_now_add, etc.) INSERT ou UPDATE SQL selon la présence d’un pk Signal post_save envoyé Aucune validation n’y figure. Ni vérification de blank, ni max_length, ni appel à clean(). C’est aussi vrai pour Model.objects.create() et Model.objects.bulk_create() : les trois méthodes persistent sans valider. (bulk_create() est traité en détail dans Django in_bulk() et bulk_create() si vous travaillez sur des insertions en masse.) ...

__add__ et __iadd__ définissent deux comportements distincts pour l’addition en Python : l’un crée un nouvel objet, l’autre modifie l’existant. Cette distinction a des conséquences réelles sur les alias et les références partagées, et elle réserve des surprises même aux développeurs expérimentés. add : l’addition qui crée __add__ est appelée par l’opérateur +. Elle doit retourner un nouvel objet et laisser les opérandes inchangés. class Vector: def __init__(self, x, y): self.x = x self.y = y def __add__(self, other): return Vector(self.x + other.x, self.y + other.y) a = Vector(1, 2) b = Vector(3, 4) c = a + b # nouvel objet Vector(4, 6) print(a.x, a.y) # 1 2 — a est inchangé print(id(a) == id(c)) # False — objets distincts a + b appelle a.__add__(b). Si __add__ n’est pas défini sur a ou retourne NotImplemented, Python essaie b.__radd__(a). ...