1 Le point de vue adopté par les auteurs concernant ce Python “starter”

1.1 L’esprit de ce starter Python

Pour être très à l’aise dans l’exploitation de ce “starter”, il vous faut être déjà relativement familiarisé avec quelques notions de programmation dans un langage quelconque. Dans le cas contraire, vous devrez avoir Wikipedia à porté de clavier et aller vérifier la signification d’un terme ou d’une notion que nous n’aurions pas explicité. Et puis vous disposez de la documentation Python ici : https://www.python.org/.

Ceci n’est pas un cours exhaustif sur Python, ni un manuel ou un “cookbook” de trucs et astuces en Python ! C’est au contraire un parcours linéaire à lire et à pratiquer séquentiellement qui vous familiarisera avec ce langage, tout en construisant pas à pas les références cognitives et/ou des pratiques utiles à la “mentalisation” d’un Python efficace, simple, propre, lisible, évolutif.

Dans un premier temps, nous vous conseillons de ne pas varier les sources d’information et d’utiliser ce “starter” le plus complètement possible. Ceci vous évitera de vous disperser et limitera le découragement qui peut advenir en feuilletant la masse d’informations sur Python.

Python est très riche et l’on peut y effectuer une opération de différentes façons, nous avons sélectionné avec soin des syntaxes efficaces immédiatement ou assez didactiques pour vous permettre d’aborder plus tard la lecture et la transcription dans votre contexte des codes Python (ou pas) que vous trouverez ici et là.

Nous avons éludé les étapes théoriques, les discussions de détail, les trucs et astuces “pythoniques”, les remarques sur le bon ou le mauvais style Python que l’on trouve un peu partout. Vous aurez tout le temps de vous faire une “philosophie” d’usage du langage pendant vos futures années de pratique. Pour autant, nous introduisons discrètement certains aspects techniques possédant une certaine profondeur théorique ou “professionnalisante” : programmation fonctionnelle, programmation objet, générateurs, tenseurs, manipulation de dataframes, SQL, …

1.2 Dénominations et conventions

En ce qui concerne la dénomination des objets/variables/fonctions que vous allez créer, ou la présentation du code, nous n’avons pas respecté “les bonnes pratiques” de la profession, en espérant faciliter la lisibilité pour un programmeur débutant. Nous avons utilisé un “franglais” peu académique que nous ne vous conseillons pas d’utiliser dans votre pratique professionnelle. De toute façon, vous devrez vous conformer aux usages de nommage de votre entité, souvent conformes à la PEP8_style_guide (https://peps.python.org/pep-0008/) que nous vous engageons à lire attentivement après avoir assimilé ce “starter” Python. A terme, nous vous suggérons d’utiliser des outils comme flake8 et pylint pour vous aider à identifier certaines bizarreries de votre code (https://flake8.pycqa.org/en/latest/ et https://docs.pylint.org/).

Pourtant, dans la mesure où cela ne nous semblait pas affecter la simplicité de notre propos, nous avons tâché de nous conformer à quelques règles simples (dont le sens vous apparaîtra peut-être plus loin dans la lecture de ce document) :

  • Les variables ou objets peu significatifs fonctionnellement comme les indices d’une boucle, les paramètres de fonctions techniques ou mathématiques revêtent la formulation la plus courte possible comme : a,b,c,d,e,f,i,j,k,l,m,n,i_,i1,i_max, A, B, X … La seule contrainte étant de limiter les ambiguïtés de lecture.

  • Les objets ayant un intérêt didactique, documentaire ou fonctionnel sont représentés en minuscules séparées par des “under_score”, exemples : f_clients, test_dispo_machin …

  • Les matrices commencent par une majuscule : A, A1, M, M_transpose.

  • les variables correspondantes à des noms classiques restent soumises aux habitudes de la profession ou du créateur d’un paquet importé, exemple : HTTPrequest.

  • les classes d’objet que nous créons au sein de notre code débutent par une majuscule, exemple : Citoyen.

  • Les variables globale ou les paramètres généraux en majuscule, exemple : P1_ALL.

  • Certains objets rappelant des objets mathématiques doivent ressembler à leur expression mathématique.

Notez les a priori suivants (qui n’ont aucune signification normative) :

  • pour les “vieux” informaticiens, les lettre i,j,k,l évoquent la notion d’indice de boucle ou de valeurs entières et que les lettre n,m évoquent des effectifs ou des dimensions, x y z des inconnues ou des valeurs “muettes”,

  • pour les utilisateurs de Python, la lettre k évoque le mot key et la lettre v le mot value, arg évoque un paramètre de fonction (“argument”)

  • par ailleurs, la lettre f évoque souvent la notion de fichier, df la notion de dataframe, o ou obj un objet, u v w des vecteurs, x y des réels ou des vecteurs de réels, le triplet (x,y,z) des coordonnées spatiales, w un poids ou un vecteur de poids (coefficients), e une notion d’erreur, c un caractère, s une string, st une série temporelle …

1.3 Zen de Python

Voici une transcription personnelle et très amendée de certains conseils du Zen du Python, de Tim Peters. Ces conseils n’ont rien d’anecdotiques, ils reflètent la façon dont vous devez aborder la programmation (Python et autres). Leur sens se précisera au fur et à mesure de votre pratique, relisez-les souvent :

  • Le beau est mieux que le laid.

  • L’ explicite est mieux que l’implicite.

  • Le simple est mieux que le complexe.

  • Le complexe est mieux que le compliqué.

  • Un style de programmation très linéaire est mieux qu’un style imbriqué.

Traduction technique : évitez les boucles inutiles et les cascades de “if then else” inutiles. Utilisez les techniques de programmation fonctionnelles : fonctions simples, générateurs/itérateurs ou map, fonction lambda. Utilisez des objets et des méthodes compactes en évitant les classes et les fonctions trop verbeuses.

  • Un langage clair est préférable à un langage dense.

  • La lisibilité importe beaucoup (traduction technique : belles indentations 2 ou 4 caractères, lignes de moins de 80 caractère, choix du nom des objets, commentaires concis et utiles, doc_string à jour … )

  • Les cas particuliers ne sont pas assez particuliers pour enfreindre les règles, bien que l’aspect pratique doive supplanter la pureté.

  • Les erreurs lors de l’ exécution du code ne doivent jamais se passer en silence (if imprévu : log et stop), sauf si elles sont explicitement réduites au silence pour une raison qui vous est propre et documentée.

Ceci impose parfois de restreindre la généricité d’un code pour faire apparaître les imprévus : déclarer le type de ses variables, tester le résultat des requêtes ou de certaines méthodes et traiter explicitement les cas où elles ne retournent rien, ou un résultat partiel (ou hors du domaine de définition des traitements qui suivent). De plus ceci impose que les codes et les libellés des erreurs soient très explicites et documentés.

  • Ne ré-inventez pas la poudre et utilisez des paquets (packages) éprouvés, mais dont vous comprenez et adhérez à la philosophie.

  • Ne copier pas bêtement les trucs et astuces, “tricks” divers trouvés ci et là : réinterprétez-les avec votre propre style de programmation (et testez-les à fond !).

Lisez régulièrement le code produit par d’autres développeurs (sur Github, Stackoverflow et https://www.programcreek.com/python/ qui permet un accès par mot contenu dans les codes).

  • Pour créer vos modèles de données, de classe et cas d’utilisation, mais aussi quand pour élaborer votre code et vos tests pensez à :

    • vous exprimer en stories : En tant que , il veux < >, afin de

    • vous exprimer en terme de règles : si ceci alors cela en relevant les exceptions à votre règle : sauf si

    • vous poser les questions clés :

      • ceci est-il une sorte de (is_a = héritage ) ?
      • ceci est-il composé de au moins 0 ou 1 et au plus 1 ou n de cela (has_a : composition/cardinalité) ?
      • vous référez à des taxonomies, ontologies, modèles de processus existants

  • Pensez à produire un code le moins adhérent possible :

    • limitez l’adhérence aux spécificités du système d’exploitation et de votre architecture matérielle (Windows, Linux, Mobile, Embarqué, GPU, nom/version de la base de donnée …)
    • référez-vous à des modèles de conception et d’exécution (MVC, API, micro-services, parallélisme, broker, containers …) et abordez les design patterns dès que vous vous en sentirez capable.

  • Face à l’ambiguïté, refusez la tentation de deviner ou de laisser deviner.

  • Etudiez les namespaces, les modules, les paquets … et utilisez-les avec discernement.

  • Utilisez sérieusement un système de test unitaire (et documentez vos tests)

  • Utilisez un système de gestion de version (et faite des commit et/ou sauvegardes régulières)

  • Quand vous prenez des décisions techniques, souvenez-vous que :

    • vous ne serez pas toujours là pour maintenir ce logiciel
    • le déploiement de ce début de vingtième siècle se fera sans doute en mode “devops” : infrastructure as a code et que tout doit donc pouvoir faire l’objet d’un script (i.e. pas de paramétrages de votre application via une IHM, sauf si cette IHM construit un script) !

  • la livraison d’un logiciel comprend un ensemble cohérent et affublé d’un numéro de version pour l’ensemble avec :

    1. le code commenté et testé,
    2. le système de tests, en particulier les tests unitaires et les données de test,
    3. la mise à jour de la documentation technique,
    4. le rappel des spécifications et/ou stories d’origines avec la mention de ce qui est fait ou pas (ou partiellement) et la liste des anomalies résiduelles,
    5. les scripts de construction documentés,
    6. la description du contexte architectural et des motivations de cette architecture,
    7. les scripts d’exploitation documentés,
    8. les restrictions d’usage éventuelles et une description des améliorations futures souhaitables,
    9. le système de test d’intégration et/ou de tests utilisateurs et la liste des anomalies résiduelles,
    10. la documentation utilisateur ou les éléments clés de celle-ci à mettre forme par une équipe dédiée,
    11. Le tout accompagné d’une note de synthèse (release note) exprimant également les évolutions par rapport à livraison précédente.

    Les points 1 et 2 ne sont pas négociables pour un Commit, les points 3 et 4 ne sont pas négociables en fin de sprint, les point 5 à 11 ne sont pas négociables avant une phase d’intégration ou de mise en exploitation.

1.4 Contexte de travail

Python est disponible en versions 2.x (typiquement 2.7) et 3.x (3.11 actuellement). Les versions 2.x de Python restent utilisées dans des contextes où la migration n’a pas été effectuée pour diverses raisons économiques ou pratiques, mais aujourd’hui il est d’usage de développer dans une version supérieure ou égale à 3.5. Afin de ne pas créer de frustrations c’est ce niveau de version que nous avons utilisé dans nos exemples.

Notez que vous pouvez disposer de plusieurs versions sur une même machine, ceci au travers de différents mécanismes, dont les environnements Python (vens) ou conda. Dans ce cas il vous faudra évoquer le bon environnement avant de commence à coder.

Dans ce starter, on suppose que Python est installé et que vous disposez d’un contexte Python supérieur ou égal à 3.5, dans lequel vous avez l’autorisation d’installer de nouveaux paquets (librairies, packages), typiquement au travers de l’instruction suivante en ligne de commande : pip install un_nouveau_paquet.

Pour tester Python en ligne sans installation sur votre machine vous pouvez utiliser :

Pour installer un paquet Python (= package, library), vous trouverez différentes façon de procéder (dans un environnement dédié ou pas en utilisant pip, pip3, conda …) utilisables en ligne de commande. Mais en utilisant un contexte en ligne pour tester Python vous ne pourrez pas souvent accéder à la ligne de commande. Pour forcer l’installation d’un paquet dans un tel environnent , sans même l’avoir identifié, vous pouvez utiliser la syntaxe suivante dans votre script Python, via l’usage du point d’exclamation : \(!\).

! pip install machin

Par ailleurs, pour vous assurer que tout va bien se passer en terme de jeu d’encodage des caractères dans votre programme, il est prudent d’insérer en début de vos programme le commentaire magique (magique : car il s’exécute alors que cela devrait réagir comme un commentaire !) suivant.

# coding: utf-8