Python : mon avis (mitigé)

Autant l'annoncer : mon avis sur Python est franchement partagé. Ce n'est pas une note pour dire qu'il est mauvais ni qu'il ne sert « pas en vrai » : il est partout (machine learning, data science, scripting, automatisation, glue entre systèmes), et prétendre le contraire serait ridicule. C'est un avis d'usage : ce que je lui reconnais, et ce qui me freine dès qu'un projet grossit.

# Ce que je lui reconnais volontiers

• La lisibilité : on lit du Python presque comme une phrase. Pour un débutant ou pour transmettre une idée, c'est imbattable.
• La vitesse de prototypage : de l'idée au script qui tourne, il y a très peu de friction.
• L'écosystème data / ML : NumPy, pandas, PyTorch, scikit-learn. Sur ce terrain, il n'a pas d'équivalent, et c'est une vraie raison de le choisir.
• Le rôle de « glue » : coller deux outils, automatiser une tâche, écrire un script jetable, il excelle.

Donc oui, je m'en sers, et je continuerai. Mais.

# Le typage dynamique : le confort qui devient un piège

Au début, ne pas déclarer les types fait gagner du temps. Sur un gros projet, ça se retourne contre toi : les erreurs de type n'apparaissent qu'au runtime, parfois en production, là où un langage typé les aurait bloquées à la compilation.

def prix_ttc(prix, taux):
    return prix * (1 + taux)

prix_ttc("10", 0.2)   # aucune erreur avant l'exécution : "10" * 1.2 -> plante ici

def prix_ttc(prix, taux):

    return prix * (1 + taux)

prix_ttc("10", 0.2)   # aucune erreur avant l'exécution : "10" * 1.2 -> plante ici

La communauté l'a bien senti : mypy et les type hints (def f(x: int) -> int:) sont venus rajouter un typage statique par-dessus. C'est un aveu utile, mais ça reste une surcouche optionnelle qu'on peut ignorer, pas une garantie du langage.

# La performance et le GIL

Python est lent comparé à du code compilé, c'est assumé. Le vrai point dur, c'est le GIL (Global Interpreter Lock) : un seul thread exécute du bytecode Python à la fois. Résultat, le multithreading n'accélère pas un calcul CPU-bound.

On contourne (multiprocessing, bibliothèques natives en C, async pour l'I/O), et les libs data poussent le lourd en C. Mais « on contourne » est justement le mot : la performance vient souvent d'autre chose que Python lui-même.

# La permissivité

Le fameux « il y a plusieurs façons de le faire ». En pratique, il y en a une bonne et plusieurs douteuses, et rien ne t'empêche d'écrire les mauvaises : muter un argument par mégarde, abuser du dynamique, monkey-patcher une classe à la volée. Le langage te fait confiance, y compris quand il ne devrait pas. À l'échelle d'une équipe, ça demande de la discipline (linters, revues) pour rester propre.

# Les environnements et les dépendances

pip, venv, virtualenv, poetry, conda, pyenv. Gérer proprement les versions et les environnements isolés reste un casse-tête récurrent, surtout entre machines et OS. Comparé au réflexe simple d'autres écosystèmes, on perd du temps là où on ne devrait pas.

# Mon verdict

Mitigé, donc, mais pas de mauvaise foi. Python est excellent pour la data, le ML, le scripting et le prototypage, et je le recommande sans hésiter pour ça. Ma réserve est ciblée : dès qu'il s'agit d'un gros système, typé, exigeant en performance et maintenu sur la durée, ce n'est pas mon premier choix, précisément à cause du typage dynamique, du GIL et de la permissivité.

Ce n'est pas « trop simple pour le pro », c'est « pas taillé pour tous les usages pro ». La nuance est importante : le bon langage dépend du problème, et Python résout très bien une grande partie d'entre eux, juste pas ceux-là.

# La suite

• Le GIL et le multithreading - le détail technique derrière le reproche sur la performance
• Python : Introduction - les bases si tu débarques
• TypeScript : pourquoi et comment - exactement la réponse au reproche du typage : ajouter un typage statique fort