setattr Python - Maîtrisez l'attribution dynamique d'attributs

Modifier un attribut à partir de son nom dynamique est une capacité très utile en Python, surtout quand les données arrivent sous forme de dictionnaire, de configuration ou de réponse d’API. La fonction setattr sert précisément à cela, mais elle n’est pas interchangeable avec une simple affectation directe. Dans cet article, je montre comment elle fonctionne, quand l’utiliser, ce qu’elle change par rapport à obj.attr = valeur, et les pièges qui comptent vraiment en pratique.

Comprendre setattr python sans confusion

En Python, setattr(obj, nom, valeur) sert à poser ou modifier un attribut sur un objet à partir d’une chaîne. En clair, au lieu d’écrire obj.host = "localhost", on peut écrire setattr(obj, "host", "localhost") quand le nom de l’attribut est calculé à l’exécution. C’est ce point qui fait toute sa valeur : la mécanique devient dynamique, pas seulement syntaxique.

Le comportement reste proche de l’affectation classique. Si l’objet accepte l’attribut, Python le stocke comme n’importe quelle autre valeur. Si l’objet impose des règles particulières, comme un contrôle d’écriture ou une structure figée, setattr respecte ces règles au lieu de les contourner. Autrement dit, ce n’est pas un raccourci pour “forcer” un objet, c’est une manière programmatique d’utiliser le même mécanisme d’attribution.

class Serveur:
    pass

srv = Serveur()

setattr(srv, "host", "192.0.2.10")
setattr(srv, "port", 8080)

print(srv.host)
print(srv.port)

Dans cet exemple, les attributs host et port n’existaient pas au départ. C’est exactement ce que permet l’écriture dynamique : créer une instance plus tard, à partir de données qui arrivent au moment de l’exécution. Une fois ce principe clair, on voit mieux dans quels scénarios il apporte un vrai gain.

Quand l’attribution dynamique rend le code plus souple

Je réserve en général cette technique aux cas où la structure varie réellement. Si les noms d’attributs sont connus d’avance, je préfère une classe explicite. En revanche, dès qu’on mappe des données externes vers un objet, setattr évite une avalanche de conditions répétitives et garde le code plus compact.

Le gain est réel quand il évite de dupliquer du code ou de multiplier des blocs if. Mais je n’en fais jamais un réflexe par défaut : dès que la structure est stable, la version explicite reste plus sûre à relire et à maintenir. C’est précisément pour ça qu’il faut regarder des cas concrets avant de trancher.

Exemples concrets avec des cas qui reviennent souvent

Le premier cas utile, c’est la boucle sur un dictionnaire. On rencontre cela dans les parseurs de configuration, les objets de formulaire ou les petites couches d’adaptation entre une API et un modèle interne.

class Config:
    pass

data = {
    "host": "localhost",
    "port": 5432,
    "debug": True,
}

cfg = Config()

for name, value in data.items():
    setattr(cfg, name, value)

print(cfg.host)
print(cfg.debug)

Un autre cas, plus subtil, concerne les noms qui ne sont pas de “bons” identifiants Python. Techniquement, Python accepte des noms d’attributs qui ne peuvent pas être écrits avec la notation pointée, mais cela complique l’usage quotidien. Je considère ce cas comme possible, pas comme souhaitable : si le nom devient difficile à relire ou à tester, il vaut souvent mieux garder une dict plutôt qu’un objet à attributs atypiques.

class Objet:
    pass

o = Objet()
setattr(o, "api-version", "v2")

print(getattr(o, "api-version"))

Le message pratique est simple : setattr sert bien quand le nom est variable, pas quand on essaie de forcer une convention de nommage bancale. C’est aussi ce qui permet de distinguer ce mécanisme des autres façons d’écrire un attribut.

setattr, affectation directe et __setattr__ ne servent pas au même niveau

Les trois approches sont proches en apparence, mais elles n’ont pas le même rôle. L’affectation directe reste la plus lisible. setattr devient intéressant dès que le nom d’attribut n’est plus connu au moment où le code est écrit. Et object.__setattr__ est un outil de niveau plus bas, réservé aux cas où l’on veut court-circuiter une redéfinition personnalisée de __setattr__ ou initialiser un objet dans un contexte particulier.

Un point important : setattr ne “bypass” pas les règles internes de l’objet. Si la classe utilise des propriétés, un __setattr__ personnalisé ou des descripteurs, l’écriture peut être validée, transformée ou bloquée. C’est utile quand on veut garder des contraintes métier, mais cela surprend souvent les débutants qui imaginent une insertion brute dans l’objet. Le sujet devient alors moins théorique et plus concret : il faut connaître les limites réelles du mécanisme.

Les pièges qui surprennent le plus souvent

Le premier piège, c’est de croire que tout objet accepte n’importe quel nouvel attribut. Ce n’est pas vrai. Une classe qui utilise __slots__, certains types intégrés ou un contrôle d’écriture strict peut refuser l’ajout d’un attribut arbitraire. Dans ce cas, Python lève une erreur au lieu d’inventer silencieusement un nouvel emplacement de stockage.

• __slots__ limite les attributs disponibles et bloque souvent l’ajout libre de nouveaux champs.
• Les propriétés déclenchent parfois une logique de validation plutôt qu’une simple affectation.
• Un __setattr__ personnalisé peut rediriger ou interdire l’écriture si la classe veut garder le contrôle.
• Le name mangling rend les attributs privés plus délicats : un nom comme __token devient en interne quelque chose de plus spécifique à la classe.
• Les entrées non validées peuvent écraser une méthode ou un attribut critique si on laisse un utilisateur choisir le nom librement.

Le dernier point est particulièrement important côté sécurité. Si le nom de l’attribut vient d’une requête, d’un fichier ou d’un flux externe, je mets toujours une liste blanche ou un schéma strict avant d’écrire quoi que ce soit. Sans cette barrière, un simple champ malveillant peut casser le comportement d’un objet ou ouvrir une porte à des effets de bord difficiles à diagnostiquer.

Autre piège fréquent : la lisibilité. Quand une équipe découvre un objet rempli d’attributs créés à la volée, elle perd rapidement la vision du contrat réel de la classe. C’est là que les outils de typage et l’autocomplétion deviennent moins efficaces, ce qui alourdit la maintenance au lieu de la simplifier.

Écrire du code dynamique sans perdre en lisibilité

Ma règle est simple : j’utilise l’attribution dynamique seulement quand elle apporte une vraie réduction de complexité. Si le champ est connu d’avance, j’écris l’affectation directement. Si le champ dépend des données, je garde setattr, mais je l’encadre avec des règles très claires.

1. Je valide les noms autorisés avant toute écriture.
2. Je garde une liste blanche des attributs acceptés quand la source est externe.
3. Je préfère une dict si la structure est trop variable pour être modélisée proprement par des attributs.
4. Je documente le contrat des champs dynamiques pour que l’équipe sache ce qui peut être créé.
5. Je teste les cas limites, surtout les noms inconnus et les valeurs manquantes.

Dans les projets où le code doit rester très lisible, j’ajoute souvent une couche d’adaptation séparée. L’objet métier reste stable, et c’est la couche d’import ou de transformation qui manipule les noms dynamiques. Cette séparation est simple, mais elle évite beaucoup de dette technique.

Si la logique devient plus complexe qu’un simple “nom + valeur”, il faut aussi se demander si l’attribut est vraiment le bon outil. Dans certains cas, un dictionnaire, un objet de configuration ou un modèle explicite est plus sain. C’est la différence entre une souplesse utile et une souplesse qui finit par masquer la structure du programme.

Le bon réflexe quand l’attribut dépend des données

Quand je résume la pratique, je reviens toujours au même arbitrage : lisibilité d’abord, dynamique seulement quand elle résout un vrai problème. setattr est excellent pour mapper des données, automatiser un peu de métaprogrammation ou alléger du code répétitif, mais il devient vite fragile si on l’utilise comme une habitude générale.

Le meilleur réflexe consiste à poser trois questions avant de l’écrire : l’attribut est-il réellement variable, la source est-elle fiable, et l’objet doit-il accepter librement de nouveaux champs ? Si la réponse à l’une de ces questions est non, je préfère une approche plus explicite. En pratique, c’est souvent ce choix qui fait la différence entre un code souple et un code pénible à maintenir.

En gardant cette logique, on profite de la puissance du mécanisme sans perdre le contrôle sur la structure du programme. C’est exactement là que Python reste intéressant : il permet d’être dynamique, mais il ne force jamais à l’être.