La prochaine édition des JRES (Journées RÉSeaux de l’enseignement et de la recherche) aura lieu du 8 au 11 décembre 2026 au palais des congrès de Tours.
L’AFPy est invitée à y tenir un stand pour présenter notre association.
Est-ce que des membres seraient intéressé·e·s pour le faire ?
Bonjour, j’ai installer mon environnement python .venv uv avec mes package flask,openpyxl et pandas. j’ai du du coup voulu teste s’ils marchait bien en faisant : python -c “import flask; import openpyxl; print(‘OK’)” mais j’ai ces erreurs que je n’arrive pas à résoudre.
File “C:\Users\FKT609835\Documents\2. ENV_TEST\Environement Python.venv\Lib\site-packages\flask_init_.py”, line 5, in from . import json as json File “C:\Users\FKT609835\Documents\2. ENV_TEST\Environement Python.venv\Lib\site-packages\flask\json_init_.py”, line 6, in from ..globals import current_app ValueError: source code string cannot contain null bytes
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).
Qu’est-ce que contient la nouvelle version de python ? Est-ce une version qui marque de gros changements ? Venez tester vos connaissances sur python 3.14 au travers un quiz et du live coding
Nous serons accueillis par nos partenaires : Coqpit qui nous met à disposition ses locaux, ainsi ITARVERNE qui nous offre de quoi poursuivre cette session autour de pizzas.
Pas de pré-requis nécessaire, même si vous ne codez pas, venez par curiosité et vous pourrez peut-être y prendre goût.
Inscription gratuite mais obligatoire : Je ne peux pas mettre de lien donc RDV sur le groupe PyClermont de meetup
Bonjour, je viens de découvrir ce forum et je me suis inscrit car pour mon master je dois maîtriser le python, je précise que je n’ai que très peu de connaissances en informatique générale
Si vous acceptez de me partager des conseils et ressources je vous en remercierais grandement !
Je vois encore passer, en 2025, du code comme ça :
def is_prime(n):
if n <= 1:
is_prime = False
else:
is_prime = True
for i in range(2, int(n**0.5) + 1):
if n % i == 0:
is_prime = False
return is_prime
Mais POURQUOI ? (ajouter un break résoudrait un problème de perfs, mais il paraît que chez les vrais puristes du SESE, break et continue sont interdits aussi, peu m’importe ici, ce n’est pas mon sujet).
Ma question est, pourquoi ne pas l’écrire de manière lisible :
def is_prime(n):
if n == 1:
return False
for i in range(2, int(n**0.5) + 1):
if n % i == 0:
return False
return True
Étant fan du early return, lire une fonction entièrement codée dans un gros if ou dans un gros else juste parce qu’on s’interdit un return ça me chagrine.
Le return alternatif de FORTRAN IV (1961)
J’ai lu quelque part que cette coutume nous viendrait des développeurs FORTRAN, qui avaient, il y a fort fort longtemps, un return alternatif, une démo s’impose :
CALL CHECK(A, B, *10, *20, C)
...
10 ...
20 ...
SUBROUTINE CHECK(X, Y, *, *, C)
...
50 IF (X) 60, 70, 80
60 RETURN
70 RETURN 1
80 RETURN 2
END
Le premier RETURN est un return normal, donc après la fin de l’exécution de la fonction CHECK l’exécution de la fonction qui a appelé CHECK reprend comme on a l’habitude.
Le RETURN 1 renvoie au premier return alternatif qui vaut *10 : donc c’est un saut au label 10.
Le RETURN 2 saute au label 20 (indiquée par le *20 côté appelant).
J’imagine (probablement pas assez, ne l’ayant pas vécu) l’enfer, et la règle est apparue « Alternate RETURNs should not be used. ». Le return alternatif aura vécu de 1961 (Fortran IV) à 1990 (F90), l’année de naissance de Python.
Et ça serait peut-être cette règle qui se serait transformée en « un seul return par fonction » qui pollue encore notre code de nos jours.
Clairement « plusieurs return » (différents points de sortie dans la fonction appelée) et « return altenatifs » (plusieurs points d’atterrissage dans la fonction appelante) n’ont rien à voir : on ne peut pas « sauver » la règle Single-Exit en la réécrivant « un seul return par fonction ».
L’entrée alternative de FORTRAN
Dans Single-Entry Single-Exit (SESE) on lit single-entry, tiens c’est quoi ça ?
Ça date de la même époque, en FORTRAN il existait un mot clé ENTRY permettant d’ajouter des points d’entrée alternatifs à une fonction.
Le fait que Single-Entry signifie « n’utilisez pas de points d’entrée alternatifs » me conforte dans l’idée que Single-Exit signifie « n’utilisez pas de return alternatifs ».
Le dogme
Si c’est le cas, c’est donc littéralement un dogme, j’imagine la scène :
Dis, Maître, pourquoi SonarCube dit qu’il faut pas deux return dans ma fonction ?
La sagesse des anciens dit « Single-Entry, Single-Exit ». Nous on fait du code de qualité, on respecte la sagesse des anciens, on respecte MISRA et l’IEC 61508, sécurité, maintenabilité, lisibilité ! Si t’es contre t’es un jeune qui va droit dans le mur, je te le dis moi, y’en a qu’on essayé, ils ont eu des problèmes… Si tu ne veux pas finir comme les développeurs du THERAC 25, réécrit ta fonction à la norme et pose pas de questions.
Maître, c’est quoi alors Single-Entry ?
J’sais pas, retourne bosser, respecte la norme, et pose pas d’questions.
Alors que SESE ne peut pas s’appliquer aux langages qui n’ont pas d’entrée alternatives ou de return alternatifs, la règle ne peut s’appliquer à aucun langage contemporain (même fortran depuis F90 n’a plus ni l’un, ni l’autre).
Le dogme survit
Les tenant du « un seul return » se sont convaincus, et le font vivre, avec des arguments variés :
Ça permet de mettre un assert au moment du return.
Ça permet de mettre un breakpoint au moment du return.
Ça permet de libérer des ressources au moment du return.
Le code après un return pourrait ne pas être exécuté.
…
Ma conclusion
Libérez-vous des dogmes des années 70 !
Rédigez le code qui est le plus lisible à vos yeux en utilisant tous les outils à votre disposition pour ça. Si ça implique parfois de n’utiliser qu’un seul return, d’accord.
Mais si ça implique de tordre le code pour arriver à un seul return, pas d’accord.