Python Crash Course

1Un cours « soigneusement trié », pas une encyclopédie

Un manuel pour débutants se juge à ce qu'il laisse de côté. Matthes l'écrit noir sur blanc dans sa préface : « mon objectif principal en révisant ce livre est qu'il reste un cours d'introduction à Python soigneusement trié » (well-curated). Concrètement, chaque édition coupe autant qu'elle ajoute. La 3ᵉ :

• remplace unittest par pytest (l'outil de tests devenu le standard) ;
• troque l'ancien open() contre pathlib (la manipulation de fichiers moderne) ;
• abandonne Heroku pour Platform.sh ;
• installe le débutant sur VS Code.

Pas de compréhensions de dictionnaires, pas de décorateurs maison, pas de métaclasses : pas parce que c'est inutile, parce que ce n'est pas le jour. Le tri, c'est ça, le vrai travail pédagogique : choisir l'ordre, le sous-ensemble, et assumer les coupes.

2Les variables sont des étiquettes, pas des boîtes

Presque tous les cours d'initiation expliquent qu'une variable est « une boîte qui contient une valeur ». Matthes corrige dès la page 18 : « cette image peut aider les premières fois, mais elle ne décrit pas fidèlement la façon dont Python représente les variables en interne. Il vaut bien mieux voir les variables comme des étiquettes qu'on colle sur des valeurs ».

La différence a l'air cosmétique, elle est fondamentale. Une boîte contient SA valeur, donc affecter devrait copier. En Python, affecter colle une étiquette de plus sur le même objet. Le jour où deux variables « partagent » mystérieusement une liste (vous modifiez l'une, l'autre change aussi), le modèle boîte s'effondre et le modèle étiquette explique tout.

Donner le bon modèle dès le chapitre 2, avant même que le piège soit possible : voilà ce qui sépare un cours pensé d'un cours récité.

3Les erreurs se provoquent exprès

Chapitre 1, exercice 1-2 : introduisez volontairement une faute de frappe dans hello_world.py et regardez ce qui se passe. Casser le programme est un exercice officiel.

Matthes provoque ensuite ses propres erreurs sous vos yeux : il écrit mesage au lieu de message et décortique le traceback ligne par ligne, en soulignant au passage que Python suggère désormais la correction. Et il désamorce la honte : « beaucoup d'erreurs de programmation sont des fautes de frappe d'un seul caractère sur une ligne. Si vous passez longtemps à en chercher une, sachez que vous êtes en bonne compagnie » (p. 18).

L'erreur n'est pas un échec : c'est la sortie standard du métier, et lire un traceback est une compétence qui s'enseigne, pas un don.

Traceback (most recent call last):
  File "hello_world.py", line 2, in <module>
    print(mesage)
          ^^^^^^
NameError: name 'mesage' is not defined. Did you mean: 'message'?

4« Mieux vaut maintenant que jamais »

À la fin du chapitre 2, Matthes fait taper import this et commente quelques lignes du Zen de Python. Celle qu'il garde pour la fin est un programme d'apprentissage à elle seule : « Now is better than never. Vous pourriez passer le reste de votre vie à apprendre toutes les subtilités de Python et de la programmation en général, mais vous ne termineriez jamais aucun projet » (p. 31).

Tout le livre découle de cette ligne : on apprend juste assez pour construire quelque chose qui marche, et on complète en route. L'anti-perfectionnisme érigé en méthode : exactement le réflexe qui manque à ceux qui collectionnent les tutoriels sans jamais rien finir.

5Le plan s'écrit en prose, le refactoring se fait en route

Le chapitre 12 ouvre le premier projet (un jeu façon Space Invaders) par une leçon de gestion de projet déguisée. D'abord : « quand on construit un grand projet, il faut préparer un plan avant de commencer à écrire du code » (p. 228). Le plan en question n'est pas une spec de quarante pages : un paragraphe en prose qui décrit le jeu.

Ensuite, le premier incrément est minuscule : une fenêtre Pygame vide qui s'ouvre et se ferme. Puis, à chaque tour, la même boucle : ajouter une petite fonctionnalité, vérifier à l'écran, et refactorer AVANT d'ajouter la suivante.

Matthes le dit en toutes lettres : « dans les grands projets, on refactorise souvent le code déjà écrit avant d'en ajouter » (p. 237), et il assume la conséquence : « on commence par écrire le code le plus simple possible, puis on le refactorise à mesure que le projet se complexifie » (p. 238). Le refactoring n'est pas le grand nettoyage de fin de chantier : c'est une étape de chaque tour de boucle.

6Tester est une compétence de débutant

C'est le choix le plus inattendu du livre : le chapitre 11, encore dans la moitié « bases », enseigne pytest. Pas en option, pas en annexe : entre les fichiers et le premier projet. L'argument est posé dès la page 2 : « tester son code est l'une des premières compétences qui font passer de débutant à programmeur intermédiaire ».

La démonstration est limpide : une fonction qui formate des noms (janis joplin en ressort en « Janis Joplin »), un test qui passe, puis on ajoute le deuxième prénom et le test casse. La règle qui suit mérite d'être gravée : « donc quand un test échoue, ne changez pas le test » (p. 215) : corrigez le code, parce que d'autres appels cassent exactement comme le test.

Et l'honnêteté rare : « ne visez pas la couverture complète sur vos premiers projets, sauf raison précise » (p. 223). Tester tôt, oui ; le dogme de la couverture, non.

from name_function import get_formatted_name

def test_first_last_name():
    formatted_name = get_formatted_name('janis', 'joplin')
    assert formatted_name == 'Janis Joplin'

7La POO sert à modéliser, pas à réciter

Le chapitre sur les classes tient en une phrase : « pensez à une classe comme à un jeu d'instructions pour fabriquer une instance » (p. 159). L'exemple fil rouge est volontairement banal : une classe Dog avec un nom et un âge, puis une Car qu'on étend en ElectricCar, dont la batterie devient une classe Battery à part.

Il nomme le procédé, la composition : la voiture ne stocke pas elle-même les caractéristiques de sa batterie, elle possède un objet Battery qui s'en charge.

class Battery:                  # une classe à part : son seul métier, la batterie
    def __init__(self, kwh=75):
        self.kwh = kwh
    def autonomie(self):
        return self.kwh * 5         # km

class ElectricCar(Car):
    def __init__(self, marque):
        super().__init__(marque)
        self.battery = Battery()    # la voiture POSSÈDE une batterie

ma_tesla.battery.autonomie()        # on délègue à l'objet qui s'y connaît

Le jour où la batterie se complexifie (recharge, dégradation, modèles), tout reste dans Battery ; la voiture n'en sait rien. Mais la vraie leçon arrive quand Matthes fait réfléchir à ce qu'on modélise : « vous ne réfléchissez plus à Python, mais à la façon de représenter le monde réel en code » (p. 173).

Et là encore, le tri : pas de @property, pas de méthodes de classe, pas de méthodes spéciales au-delà de __init__. Modéliser d'abord, la syntaxe avancée attendra.

8Trois projets, trois portes d'entrée dans le métier

La seconde moitié du livre, ce sont trois projets complets et indépendants, à faire dans l'ordre qu'on veut :

• un jeu (Alien Invasion, avec Pygame) ;
• de la visualisation de données (matplotlib puis Plotly) ;
• une application web (un journal d'apprentissage en Django).

Trois projets = trois métiers possibles, et le lecteur choisit sa porte. Le détail qui change tout : les données sont vraies. La météo vient des relevés NOAA de Sitka, en Alaska, et de la Vallée de la Mort ; les séismes du flux temps réel de l'USGS ; le classement des dépôts les plus étoilés de l'API GitHub. Et le projet Django va jusqu'au bout : Bootstrap, comptes utilisateurs, et déploiement réel sur Platform.sh, DEBUG=False compris. Un livre pour débutants qui se termine avec votre application en ligne, c'est encore l'exception.