Programmation Python
Publié le par Gilbert MOISIO

Python

Dernière modification le 2 juin 2021

Au-delà des guerres de religions sur les langages, il est clair que dans le domaine des réseaux et de l’automatisation, c’est le langage Python qui est prédominant. Dans la mesure où il est très répandu dans beaucoup d’autres secteurs, il existe de nombreux cours et tutoriaux accessibles sur internet. Il était commun de dire que pour le réseau, c’était Python2 le plus adapté car de nombreuses librairies n’étaient pas encore portées sur Python3. Python 2.7 ne sera plus maintenu après janvier 2020, il est donc temps de passer à la version 3 pour ceux qui ne l’avaient pas encore fait.

CPython est l’implémentation originale de Python, il est le premier à implémenter de nouvelles fonctionnalités. C’est l’implémentation qui est téléchargeable depuis python.org. On l’appelle CPython pour le distinguer des autres implémentations Python (Jython, IronPython, PyPy…) et pour distinguer l’implémentation du moteur de langage du langage de programmation Python lui-même. CPython est implémenté en C. Il compile le code Python en bytecode (de manière transparente) et interprète ce bytecode dans une boucle d’évaluation.

L’objectif, ici, n’est pas de proposer la moindre présentation de ce qui est censé être un prérequis. En revanche, des cheat sheets sont toujours pratiques pour servir de fiches de rappel.

Les « Python Enhancement Proposals » sont des documents de conception fournissant des informations à la communauté Python ou décrivant une nouvelle fonctionnalité de Python, de ses processus ou de son environnement. S’il ne devait y en avoir qu’un seul à connaitre c’est le PEP 8 « Style Guide for Python Code » qui propose des bonnes pratiques à adopter.

Je vais répondre à quelques questions qui me sont souvent posées :

  • Quelle est la bonne pratique pour le shebang ?
    Le shebang permet de lancer le script sans spécifier, sur la ligne de commande, l’interpréteur devant être utilisé. La bonne pratique consiste à essayer d’être le plus compatible possible avec les différentes plateformes en spécifiant la version de Python et en utilisant le chemin disponible dans la variable d’environnement plutôt qu’en le spécifiant en dur : #!/usr/bin/env python
  • Faut-il spécifier le test if __name__ == '__main__': que l’on voit dans beaucoup d’exemples sur internet ?
    Contrairement à d’autres langages comme le C, le Java ou le C#, Python n’a pas de fonction ou méthode main(). Quand on lance un script, tout le code est exécuté. Cela peut poser un problème quand on a un script qui contient du code que l’on souhaite exécuter quand on lance le script directement, mais pas quand on l’importe dans un autre script.
    C’est donc un choix à réaliser en fonction de l’usage que l’on souhaite faire du script.
  • Quel est l’intérêt d’utiliser un environnement virtuel et comment le mettre en oeuvre ?
    Un environnement virtuel est un outil pour garder les dépendances requises par différents projets dans des emplacements séparés, en créant des environnements virtuels Python pour eux. Cette approche permet de travailler parallèlement sur plusieurs projets dont les versions de dépendances pourraient être différentes.
    De façon basique, pour le mettre en oeuvre en Python3, les commandes utiles appliquées à un projet appelé nornir sont les suivantes :
python3 -m venv nornir
cd nornir
source bin/activate
deactivate

Même s’il est possible de créer l’environnement virtuel dans un sous répertoire différent du répertoire de l’application pour un même projet, on arrive vite à la limite de cette approche. L’utilisation de virtualenvwrapper devient rapidement un outil utile. Il permet de concentrer tous les environnements virtuels dans une même arborescence et de passer rapidement d’un environnement à l’autre à l’aide d’un ensemble de commandes et de scripts qui font gagner beaucoup de temps et permettent une organisation totalement transparente pour les applications.

mkvirtualenv <envname>
workon  <envname>
deactivate
# Virtualenvwrapper
export WORKON_HOME=~/.virtualenvs
export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python3
mkdir -p $WORKON_HOME
source /usr/local/bin/virtualenvwrapper.sh
proj_name=$(basename $VIRTUAL_ENV)
cd ~/Projects/$proj_name
cd ~/Projects/
  • Comment facilement faire du debug en Python ?
    Il existe deux approches. Soit on utilise un IDE qui intègre cette fonction, soit on fait appel aux modules pdb ou ipdb. L’objectif de pdb est de mettre un point d’arrêt dans le programme pour analyser la situation à cet instant précis et faire avancer progressivement le programme tout en gardant la main sur l’état de l’environnement.
  • Est-ce que le langage Python est adapté pour les projets commerciaux ?
    Il est vrai que ce langage est souvent utilisé pour les projets Open Source, mais je crois deviner la question qui se cache derrière. Etant un langage interprété, on aurait tendance à penser que tout le monde pourra voir la source et qu’il sera facile de la copier sans l’acheter. Je pense qu’il existe plusieurs réponses à cela. Si on ne veut vraiment pas utiliser un langage interprété, il y a toujours la possibilité de programmer en Golang, ce qui permettra de distribuer un exécutable sans sa source. On peut aussi rester en Python et adopter un modèle économique dans lequel le produit est Open Source mais l’assistance est payante. C’est un modèle qui est beaucoup utilisé aujourd’hui, en offrant l’avantage de profiter de la force d’une communauté dans un modèle gagnant/gagnant et de garder la maîtrise profonde du produit pour vendre du service. Il est aussi possible de distribuer une application Python dans un conteneur Docker offrant des fonctions documentées sans pour autant accéder à la source embarquée. Tout ceci étant dit, je ne crois pas trop au produit final NetDevOps générique, si c’est de cela dont on parle. Certes, on utilise des outils génériques, mais pour constituer une solution sur-mesure adaptée au contexte et qui reste la propriété du client une fois réalisée…