Variables et constantes en Python : comprendre la portée et les bonnes pratiques

J’explique ici, de manière pragmatique et issue de mon expérience de développeur senior, comment maîtriser les variables et les constantes en Python pour écrire un code lisible, testable et performant. Dans cet article je déroule la règle LEGB, montre des exemples concrets, partage des pièges courants que j’ai rencontrés en production et des astuces pour éviter les bugs liés à la portée. Si vous voulez du code clair, suivez les bonnes pratiques et adoptez des patterns simples que j’utilise au quotidien.

En bref :

• LEGB : Local → Enclosing → Global → Built-in, l’ordre de résolution des noms.
• Évitez de masquer les fonctions intégrées et préférez des noms descriptifs (PEP 8).
• Utilisez global/nonlocal avec parcimonie, préférez les paramètres et retours.
• Constantes : convention MAJUSCULES pour la lisibilité et la maintenabilité.
• Outils : diagnostics avec globals()/locals() uniquement en lecture pour le débogage.

Réponse rapide : La portée en Python suit la règle LEGB ; les variables assignées dans une fonction sont locales, les fonctions imbriquées voient les variables englobantes en lecture et requièrent nonlocal pour les modifier, et global permet d’affecter le niveau module. Privilégiez les paramètres et retours et n’ombrez pas les built-ins.

Variables et constantes en Python : définitions et bonnes habitudes (VariableVision)

Lorsque j’ai commencé à coder, j’ai eu plusieurs bugs dus à de mauvais noms ou à l’ombre d’un built-in. Aujourd’hui, j’applique des conventions strictes qui évitent ces erreurs.

• Variable : nom lié à un objet via =. Exemples : customer_name = « Ava », order_count = 3.
• Constante : conventionnelle, écrite en MAJUSCULES (API_TIMEOUT = 30).
• Convention de nommage : utilisez snake_case pour les variables, évitez les mots-clés et les noms commençant par un chiffre.

Voici quelques règles pratiques que j’applique systématiquement pour garder un code CodeClairPython :

• Noms descriptifs : customer_list plutôt que list.
• Ne pas réaffecter les built-ins (list, dict, sum).
• Limiter la portée : définir la variable dans l’espace le plus restreint possible.

Exemples rapides et erreurs fréquentes

J’ai souvent vu ces erreurs en revue de code : noms avec espaces, identifiants commençant par un chiffre, et masquage des built-ins.

• Erreur de syntaxe : first string value = « First » (espaces interdits).
• Nom invalide : 1st_value = 10 (ne peut commencer par un chiffre).
• Mot-clé : True = « yes » (impossible d’affecter un mot-clé).

Insight : des conventions simples réduisent les revues de code à de la pure formalité.

Comprendre la portée en Python : règle LEGB et comportements (PortéePro, ScopeSavant)

Quand un bug survient avec « nom non défini » ou « variable locale référencée avant attribution », la portée est presque toujours la cause. J’explique ici la règle LEGB et comment l’appliquer dans des cas réels.

• Local : variables d’une fonction.
• Enclosing : fonctions englobantes (fermetures).
• Global : espace de noms du module.
• Built-in : noms fournis par Python (len, print).

La portée correspond aux espaces de noms consultés lors de la résolution d’un identifiant. Comprendre cet ordre évite des erreurs comme UnboundLocalError.

Portée locale et UnboundLocalError

Python décide de la portée pendant la compilation d’une fonction. Si une variable est assignée n’importe où dans une fonction, Python la considère comme locale.

• Cas courant : lire une variable globale avant de l’assigner localement provoque UnboundLocalError.
• Solution : éviter d’assigner, renommer, ou utiliser global si nécessaire.
• Anecdote : dans un projet e‑commerce, une mauvaise gestion du discount_rate a causé un calcul erroné pendant 24h ; corriger la portée a résolu le bug.

Portée englobante et nonlocal

Pour les fonctions imbriquées qui conservent un état, utilisez nonlocal pour réassigner la variable de la fonction parente.

• Pattern closure : compteur ou accumulateur (make_step_counter, make_accumulator).
• Quand utiliser : conserver un état entre appels sans exposer d’état global.
• Piège : nonlocal sur un nom qui n’existe pas dans la portée englobante provoque SyntaxError.

Insight : les fermetures sont puissantes mais demande une déclaration explicite pour la réaffectation.

Variables globales, intégrées et diagnostics (PyBonnePratique)

J’utilise peu de variables globales en production : elles compliquent les tests et le raisonnement. Voici comment je les gère et comment utiliser globals()/locals() pour déboguer sans créer de dettes techniques.

• globals() renvoie le dictionnaire de l’espace de noms du module ; utile pour inspection.
• locals() renvoie un snapshot des variables locales (à partir de Python 3.13 c’est un instantané).
• Ne pas utiliser ces fonctions pour modifier l’état — préférez les paramètres et retours explicites.

Pratique : pour filtrer les noms système, j’utilise une simple fonction is_dunder pour ignorer les variables encadrées par __.

Built-ins et masquage

Masquer un built-in (par ex. assigner print = 9) casse des comportements attendus. J’ai vu une défaillance sur un script de reporting parce que print avait été réaffecté.

• Évitez : noms comme list, dict, sum.
• Si vous masquez par erreur, supprimez le nom (del nom) pour restaurer le built-in.
• Ultime recours : manipuler builtins.__dict__ (fortement déconseillé).

Insight : préserver l’accès aux built-ins évite des débogages longs et coûteux.

Bonnes pratiques, constantes et style (ConstanteCréative, PyCodeExpert)

Je structure mes modules avec des constantes en tête, fonctions pures, et peu d’état global. Ce pattern facilite l’audit et le SEO technique quand on documente le code.

• Définir les constantes en MAJUSCULES (e.g. API_TIMEOUT = 30).
• Favoriser les fonctions pures : entrée → sortie, sans effets de bord.
• Utiliser des modules dédiés pour l’état (si absolument nécessaire) et documenter l’usage.

Je recommande aussi d’outiller la base de code avec des linters et tests unitaires qui détectent l’ombre des built-ins et les usages incorrects de global/nonlocal.

Règles pratiques que j’applique

• Limiter la portée : variables au plus bas niveau possible.
• Paramètres et retours : privilégier la transmission explicite de données.
• Nom interne : préfixer par un underscore pour indiquer une utilisation privée (_cache).

Insight : un style consistant est la meilleure garantie contre les bugs de portée.

Cas pratiques, débogage et ressources utiles (InitiationPython, PyBonnePratique)

Je partage ici des extraits que j’utilise pour diagnostiquer des anomalies et des ressources que je consulte régulièrement pour me tenir à jour.

• Débogage rapide : inspecter globals(), exécuter des tests isolés.
• Réécriture : extraire du code en fonctions pures pour reproduire et corriger.
• Ressources : lire des bilans et analyses pour comprendre l’évolution des outils en 2025.

Pour approfondir l’écosystème Python et ses bibliothèques, je recommande cet article sur les meilleures bibliothèques Python en 2025.

• Analyse des meilleures bibliothèques Python en 2025
• Article sur l’impact technologique
• Ressource administrative et automatisation
• Étude sur la valeur des rouleaux (contexte économique)
• Exemple d’application IA et automatisation

Insight : les bonnes pratiques sont durables et s’appliquent même avec l’évolution des outils.

Checklist rapide pour corriger une erreur de portée

• Repérer si la variable est assignée dans la fonction (compilation).
• Renommer pour éviter l’ombre d’un nom global ou built-in.
• Utiliser global/nonlocal seulement si nécessaire et documenter.
• Extraire en fonction pure pour faciliter les tests.

Insight : une checklist simple évite les aller-retour en revue de code.

Que signifie la règle LEGB et pourquoi est-elle importante ?

LEGB est l’ordre de recherche des noms : Local, Enclosing, Global, Built-in. Comprendre cet ordre permet d’anticiper où Python va chercher la valeur d’un identifiant et d’éviter des erreurs comme NameError ou UnboundLocalError.

Quand utiliser global et nonlocal ?

Utilisez global pour réaffecter une variable au niveau module depuis une fonction, et nonlocal pour modifier une variable dans la fonction englobante. Ces mots-clés doivent rester rares ; privilégiez les paramètres et retours.

Faut-il éviter complètement les variables globales ?

Idéalement oui pour la testabilité et la maintenabilité. Si vous en avez besoin, regroupez-les dans un module spécifique et documentez leur usage.

Comment éviter de masquer un built-in ?

Ne nommez pas vos variables list, dict, sum, id, print. Si vous avez masqué un built-in par erreur, supprimer le nom (del) restaure le comportement intégré.