Python : `__getattr__` Et Variables Non Définies Dans `__init__`

Salut les geeks de Python ! Aujourd'hui, on plonge dans un petit casse-tête qui peut vous donner du fil à retordre si vous ne faites pas attention : la gestion des variables non définies dans le constructeur __init__ d'une classe, surtout quand votre classe utilise __getattr__. C'est un truc assez subtil mais super important à capter pour écrire du code plus robuste et éviter des bugs qui font mal à la tête. On va décortiquer ça ensemble, étape par étape, avec un exemple concret pour que ça rentre bien dans le ciboulot.

Le piège de __init__ et des attributs non initialisés

Alors, comment ça se passe dans Python ? Quand vous créez une instance d'une classe, l'interpréteur appelle d'abord la méthode __init__ pour initialiser votre objet. C'est là que vous mettez normalement la plupart de vos attributs, genre self.truc = valeur. Mais que se passe-t-il si, par mégarde, vous oubliez de définir un attribut, ou pire, vous tapez mal son nom ? Dans la plupart des cas, Python va lever une AttributeError dès que vous essayerez d'y accéder. C'est le comportement normal et attendu, ça vous dit : "Hey, tu as cherché un truc qui n'existe pas ici !". C'est une mesure de sécurité pour vous aider à débusquer les erreurs de frappe ou les logiques foireuses. Cependant, les choses se compliquent quand notre classe a aussi une méthode __getattr__.

La méthode __getattr__(self, name) est une méthode spéciale en Python. Elle est appelée uniquement lorsque vous essayez d'accéder à un attribut qui n'a pas été trouvé dans l'instance de l'objet, ni dans sa classe, ni dans ses classes parentes. En gros, c'est le filet de sécurité ultime pour les attributs. Si __getattr__ est définie, Python va l'appeler à la place de lever directement une AttributeError. C'est super utile pour créer des objets dynamiques, des wrappers, ou gérer des accès à des données de manière flexible. Mais attention, car l'interaction entre une variable oubliée dans __init__ et la présence de __getattr__ peut mener à des situations inattendues. Si l'erreur se produit avant que Python n'ait eu le temps de chercher dans les méthodes spéciales, l'histoire est différente. On va voir ça tout de suite.

Le cas pratique : ddd dans __init__

Jetons un œil à l'exemple que vous avez partagé. On a une classe Aaa simple. Dans son __init__, on a un pass suivi de ddd. Ce ddd tout seul, sans être assigné à une variable, sans être une instruction valide, c'est le cœur du problème. Quand vous créez une instance de Aaa avec Aaa(), Python essaie d'exécuter __init__. À la ligne ddd, l'interpréteur Python ne sait pas ce que c'est. Il n'est ni une variable définie, ni une fonction, ni une méthode. C'est donc une erreur de syntaxe ou une erreur de nom qui se produit immédiatement lors de l'appel à __init__. Et là, c'est là que ça devient intéressant : __getattr__ n'a même pas la chance d'intervenir ! L'erreur est trop précoce, trop fondamentale. Python va lever une NameError (ou potentiellement une SyntaxError selon le contexte exact et la version de Python) parce que ddd n'est pas défini dans le scope actuel au moment où il est rencontré dans __init__. C'est avant que l'objet ne soit complètement construit et prêt à passer par le mécanisme de __getattr__ pour les accès ultérieurs à des attributs.

Le code print("■__getattr__■") dans __getattr__ ne sera donc jamais exécuté dans ce scénario. La méthode __getattr__ est conçue pour intercepter les accès à des attributs qui existent conceptuellement mais ne sont pas directement présents sur l'instance ou la classe. Par exemple, si vous faisiez instance.attribut_inexistant après que __init__ se soit terminé sans erreur, alors __getattr__ serait appelée avec att = 'attribut_inexistant'. Mais ici, l'erreur survient pendant l'exécution de __init__ lui-même, avant même que l'objet ne soit considéré comme correctement initialisé. C'est une distinction cruciale : une erreur pendant l'initialisation vs une erreur lors de l'accès à un attribut d'un objet déjà (supposément) initialisé.

La différence avec un accès après initialisation

Pour bien piger la différence, imaginons un scénario où __init__ se passe bien, mais où vous essayez d'accéder à quelque chose qui n'est pas là. Dans notre classe Aaa, si on corrigeait __init__ pour qu'il ne pose pas de problème, par exemple en le laissant vide def __init__(self): pass, et qu'ensuite on faisait :

obj = Aaa()
print(obj.quelque_chose)

Là, oui, Python ne trouverait pas quelque_chose directement sur obj ou dans la classe Aaa. Il passerait alors la main à __getattr__. Et là, vous verriez le fameux ■__getattr__■ s'afficher, suivi de None (puisque __getattr__ retourne None). C'est le comportement attendu quand __getattr__ est là pour gérer les accès dynamiques ou les attributs potentiels. C'est un moyen de dire : "Si tu ne trouves pas, demande-moi, je vais voir ce que je peux faire".

Mais dans le cas original avec ddd dans __init__, c'est différent. L'erreur NameError (ou similaire) qui survient à la ligne ddd coupe net l'exécution de __init__. L'objet Aaa() n'est même pas correctement créé. Le processus d'instanciation échoue avant d'arriver à un état où les méthodes d'accès aux attributs comme __getattr__ pourraient être utiles. C'est pourquoi le code dans __getattr__ ne s'exécute jamais. Le problème n'est pas un attribut manquant lors d'un accès, mais une instruction invalide pendant la création de l'objet. C'est une nuance fondamentale qui sépare les erreurs d'exécution standard des mécanismes de gestion d'attributs dynamiques de Python. C'est un peu comme si vous essayiez de construire une maison, mais que vous faisiez une erreur dès le plan de fondation ; la maison entière ne pourra jamais être construite, peu importe à quel point vos finitions intérieures sont géniales.

__getattr__ : le gardien des attributs manquants

Maintenant, parlons plus en détail de __getattr__, ce super-pouvoir que Python nous donne pour gérer les accès aux attributs de manière plus souple. Imaginez que vous ayez une classe qui doit interagir avec une API externe, ou charger des données depuis une base de données, ou même simuler des attributs qui n'existent pas physiquement mais qui peuvent être calculés à la volée. C'est là que __getattr__ brille. Quand vous essayez d'accéder à un attribut d'une instance, Python suit un ordre précis : il cherche d'abord dans le dictionnaire de l'instance (__dict__), puis dans le dictionnaire de la classe, et enfin dans les dictionnaires des classes parentes. Si l'attribut n'est trouvé nulle part, et que la classe a une méthode __getattr__, Python l'appelle en lui passant le nom de l'attribut recherché comme argument. C'est votre chance de renvoyer une valeur, de lever une AttributeError personnalisée, ou de faire toute autre logique nécessaire.

L'intérêt principal de __getattr__ réside dans sa capacité à créer des objets qui se comportent comme s'ils avaient beaucoup plus d'attributs qu'ils n'en ont réellement en interne. Par exemple, vous pourriez avoir un objet représentant un utilisateur, et au lieu de stocker tous les détails possibles de l'utilisateur (adresse, numéro de téléphone, date de naissance, etc.) en permanence, vous pourriez les charger uniquement lorsque l'attribut correspondant est demandé. Si vous demandez utilisateur.adresse, __getattr__ pourrait aller chercher l'adresse dans une base de données, la stocker pour les futurs accès (en l'ajoutant au __dict__ de l'instance pour que __getattr__ ne soit plus appelée pour cet attribut), et la retourner. Si vous demandez utilisateur.age, qui n'est pas directement stocké mais peut être calculé à partir de la date de naissance, __getattr__ pourrait calculer l'âge et le retourner.

Quand __getattr__ est appelée (et quand elle ne l'est pas)

Il est crucial de comprendre le timing de l'appel à __getattr__. Comme mentionné précédemment, elle n'est appelée que lorsque l'attribut n'est pas trouvé par les mécanismes de recherche standards de Python. Cela signifie que si un attribut est défini dans __init__, ou s'il est défini plus tard directement sur l'instance, __getattr__ ne sera jamais invoquée pour cet attribut. C'est un mécanisme de