Modules et documentations

Signaler

Que l’on distribue du code ou que l’on utilise l’offre pléthorique de modules Python, la manipulation des modules et de la documentation fait partie intégrante du développement logiciel.

I. Programmation modulaire

1) Principes généraux

Le principe de modularité est particulièrement important dans tout développement logiciel. Il simplifie les tests, permet de réutiliser du code, et facilite la maintenance. Ce principe peut opérer à plusieurs niveaux :

découper le code en fonctions ;

grouper les fonctions dans une classe (on les appelle alors méthodes) ;

grouper des fonctions par thèmes, dans un fichier séparé ;

grouper des fichiers en bibliothèques.

La programmation modulaire intervient :

lors de l’écriture de portions de code pour les réutiliser plus tard, ou les distribuer ;

lors de l’utilisation, pour répondre à un besoin, de code écrit par un∙e autre.

2) Modularité en Python

On peut (on doit…) écrire des fonctions et des procédures, et les réutiliser.

Python permet de faire de la programmation orientée objets et donc de grouper des fonctions (alors appelées méthodes) au sein de classes, selon le type d’objet sur lequel elles agissent.

Fonctions, procédures et classes peuvent être groupées par thèmes dans des fichiers séparés alors appelé modules qui peuvent être groupés en packages.

II. Importation des modules

Certains modules Python sont installés par défaut (bibliothèque standard) et d’autres peuvent être ajoutés en utilisant des outils comme pip. Le dépôt Pypi (Python Package Index, https://pypi.org/) référence la plupart des modules tiers.

Pour importer un module installé, on utilise le mot clé import dans une de ses variantes. Voici des exemples avec le module random :

On importe le module random, les fonctions du module doivent être préfixées du nom du module :

2c36f21c-f52d-4d86-b386-3d4d9d1c89f7

On importe le module random et on le renomme en rnd (le nouveau nom donné est généralement plus court) :

06ed34c4-6f95-4c13-a6dc-49019a168a8d

On importe uniquement la fonction randint du module random (plus de préfixe, mais seule la fonction randint est disponible) :

19bec504-c38a-4b34-a0a4-09214f6fa5f5

Toutes les variantes contenant des * dans la ligne d’importation visent à rendre disponibles des fonctions sans avoir à les préfixer, ce qui peut paraître efficace pour le programmeur débutant. En réalité, il n’en est rien : on ne maîtrise plus la liste exacte de ce qui est importé dans l’espace de noms principal, ce qui peut être source de bugs complexes à découvrir. De plus, en reprenant plus tard son travail ou en le distribuant, on n’aura plus de trace simple de l’endroit où se trouvent les fonctions et classes utilisées, rendant la maintenance difficile : import * est à bannir !

III. Documentation

Que l’on écrive ou qu’on utilise une fonction ou un module, la documentation est centrale pour que le travail soit réutilisable.

Parmi les différents mécanismes, l’un des plus simples est la docstring qui peut être attachée à une fonction, à une procédure, à une méthode, à une classe, à un module, ou à un package. Dans tous les cas, c’est une chaîne de caractères qui doit figurer au début de l’entité qu’elle documente.

Cette documentation est ensuite consultable à l’aide de la commande help :

78a7eb32-1365-47ea-a748-1bb4f56be73f

Exemple d’écriture d’une docstring :

0fea2d59-9688-483e-9e0c-53a3445120a9