Nouvelles projet py-edu-fr : formation "Python initiation"

Salut,

Nous allons enfin réussir à baser une formation en présentielle (pour doctorants) que nous donnons à Grenoble sur du contenu py-edu-fr! Cette session se tiendra la semaine du 15 décembre 2025, i.e. dans un peu moins d’un mois.

Le contenu (https://python-cnrs.netlify.app/edu/init/) n’est pas encore vraiment prêt (il reste notamment des TP à rajouter et il y a plein de choses à améliorer/équilibrer/repenser) mais ça commence à être montrable.

En tout cas, je pense que ce qu’il y a maintenant commence à permettre de voir ce que ça va donner et que des relectures seraient très utiles. Donc si ça vous intéresse et que vous avez un peu de temps, n’hésitez pas à jeter un coup d’œil et à donner votre avis (sur ce fil de discussion, par des issues https://foss.heptapod.net/py-edu-fr/py-edu-fr/-/issues ou même des merge requests https://python-cnrs.netlify.app/contribute).

Pierre

1 « J'aime »

o/

J’ai relu jusqu’à Python scientific ecosystem.

Je trouve ça globalement très bien, je te laisse mes notes :

Tu peux conseiller le paquet python-is-python3, et peut-être python3-full a la place de python3-venv : python3-full est pas mal :

$ apt-cache depends python3-full
python3-full
  Dépend: python3
  Dépend: python3.13-full
  Dépend: python3-venv
  Dépend: idle
  Dépend: python3-gdbm
  Dépend: python3-tk
  Recommande: python3-doc
  Recommande: python3-examples
  Suggère: python3-dev

mais bon ils n’auront ni besoin de gdbm ni de tk donc ça ne change rien…

Et uv devrait arriver dans Debian, il faut suivre : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069776

Plus loin, Warning Never use except: est très très juste, mais peut-être à rephraser, j’ai peur qu’un débutant lise Warning Never use except.

But warning, dict are not ordered (since they are based on a hashtable)!

Ils le sont depuis Python 3.6 et c’est garanti depuis Python 3.7. Attention il ne faut pas mélanger “sorted” et “ordered” là : ils conservent leur ordre d’insertion, ce n’est pas un tri.

Dans Standard structure of a Python module je conseillerai d’ajouter une fonction main appelée depuis le if : ça évite de laisser la variable l fuir dans l’espace de nommage du module. Et le main grossit toujours, si on laisse le code dans le if ça fait pas mal de variables globales.

Dans la POO, si tu peux glisser qu’une classe sert d’abord a ranger ensemble des attributs qui vont ensemble. Ça aide énormément les débutants, qui ont tendance à utiliser des classes pour ranger des fonctions qui vont ensemble.

Attention dans Solution 2: add functions il y a des annotations de type alors qu’elles n’ont jamais été introduites. Je pense qu’il faut repousser leur introduction.

Un peu plus loin il y a def __init__(self, wind: list[float], temperature: list[float]):, suivi de self.wind = list(wind). J’adore le self.wind = list(wind) ça a plein d’avantages :

  • L’objet sait que self.wind est une liste (méthodes prévisibles).
  • Lève une exception tôt si wind n’est pas itérable.

Par contre utiliser list en annotation de type c’est faux car cette fonction fonctionne très bien (entre autre grâce au self.wind = list(wind)) si on lui passe un tupleun générateur, ou tout autre itérable (dit autrement : vive le duck typing), c'est doncIterable[float]`.

Pour bien fonctionner avec le duck typing les annotations de paramètres doivent être le plus laxistes possibles, alors que les annotations de valeurs renvoyées peuvent être stricts (un return [i for i in ...] est une liste, on le sait, autant l’annoter comme ça, pas besoin de dire “c’est vaguement un itérable”, non, c’est une liste).

example_py_package/pyproject.toml a une licence license = {text = "MIT"}, depuis je-ne-sais-plus-quelle-pep ça doit être simplifié en license = "MIT".

La sortie de pdm sync --clean; pdm run example-py-simple est beaucoup trop longue.