Manual:Coding conventions/Python/fr

Cette page contient les règles de codage  pour les projets Python faisant partie du projet MediaWiki lui-même et de ceux qu'il supporte.

Préambule
Vous devez vous rappeler d'abord que les règles de codage ne sont que des indications pouvant être outrepassées s'il existe une bonne raison.


 * Visez la lisibilité et l'évidence plutôt que la stricte adhérence dans le souci de respecter absolument.
 * Le code est lu beaucoup plus souvent qu'il n'est écrit.
 * Soyez cohérent avec le code existant et utilisez votre meilleure appréciation. Si ce n'est pas trop difficile de modifier le code existant, soyez gentil.

Pour tout ce qui ne se trouve pas dans ce document, voir la Proposition 0008 d'extension de Python (PEP8) qui décrit l'utilisation générale. Les sections suivantes sont pour la plupart un résumé des sections qui référencent le plus la PEP8.

Version Python
La version minimale supportée est la 2.7, mais pour certains cas particuliers des versions plus anciennes encore sont acceptées.

Si vous ne l'avez pas déjà fait, passez à Python 3 pour vos développements locaux.

Caractère espace
L'indentation des lignes doit se faire avec 4 espaces.

Les lignes en fin de fichier doivent se terminer par un passage à la ligne suivante, tout comme les autres lignes du fichier.

Essayez d'avoir des lignes de moins de 80 caractères, mais visez la lisibilité et l'évidence plutôt que la stricte adhérence dans le souci de respecter absolument. Les lignes plus courtes ne sont qu'un effet de bord de la bonne concision de Python - des noms courts et bien significatifs, pas de code en escalier, etc. Lorsque vous coupez des lignes, choisissez évidemment la méthode la moins ambigüe selon la situation.

Structure des modules
La manière classique de distribuer les modules Python est de créer un fichier  et de mettre à niveau une bibliothèque appelée « distribute ». Certains modules génèrent la structure de base du projet pour vous; c'est le cas de  mais il est obsolète et n'est plus maintenu. Une solution utilisable est pythong.

En général, les modules ont la structure suivante : newproject ├── bin ├── distribute_setup.py ├── docs ├── newproject │    └── __init__.py ├── setup.py └── tests ├── __init__.py      └── newproject_tests.py

Les import
Dans un fichier il est souvent intéressant d'organiser les imports d'une certaine façon. Typiquement on préfère les placer dans l'ordre alphabétique, mais l'ordre peut être cassé si vous importez un grand nombre de bibliothèques. To help avoid this, it's good to separate out imports in this fashion, with each block separated from the others by an empty line:


 * Imports de bibliothèques standards
 * Imports tiers
 * Import de vos bibliothèques

Voici quelques schémas à éviter :

Exemples d'import développés
Here is a more detailed abstracted version (the comments are just for explanation purposes):

Docstrings et annotation des fonctions
Generally all but the simplest functions should have docstrings. These are standardized in PEP 257

This makes it possible to automatically generate docs, as well as use Python's built-in  function.

Dans Python 3.3 et plus récent, PEP 3107 donne la syntaxe pour l'annotation des fonctions.

Function annotations do not have a completely set use case, but a common emerging case is for improved help docs and for type annotation.

Conflicts de nommage
Conflicting with builtins is a somewhat common problem. There are some builtin names (like  and  ) that you may want to use in your code. The PEP8 way to deal with these conflicts is by appending an underscore to the name, such as  or   (although if you're naming a variable   that may be a code smell).

If you find yourself in conflict with the name of some part of another module,  is your friend.

Voir aussi

 * Règles du développement Pywikibot
 * Python : site web officiel