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.
Nos derniers travaux sur Canaille financés par la fondation NLNet nous amènent à sortir une version bêta. Faisons le point.
Derniers travaux
Gestionnaire de tâches
Nous avons implémenté un gestionnaire de tâches qui permet à Canaille d'effectuer les tâches longues de manière asynchrone.
C'est utilisé notamment pour propager les requêtes SCIM ou les envois de mail.
L'implémentation utilise dramatiq, et nous avons publié le paquet dramatiq-eager-broker qui permet de conserver un comportement synchrone dans la suite de tests, et dans le cas où le gestionnaire de tâches ne serait pas configuré.
Certification OpenID Connect
Nous vous en parlions récemment, Canaille a obtenu au mois de septembre dernier la certification de la fondation OpenID Connect.
Cela garanti que Canaille a un comportement conforme pour la plupart des opérations OpenID Connect courantes.
Le processus de certification a révélé beaucoup d'erreurs d'interprétation, souvent mineures mais parfois importantes.
Nous avons corrigé la plupart des problèmes directement dans Authlib, la bibliothèque sous-jacente d'implémentation des normes.
Securité
Nous avons implémenté les recommandations restantes issues de l'audit de Radically Open Security.
La plupart étaient des recommandations mineures relevant des bonnes pratiques, mais il y avait tout de même une vulnérabilité à niveau de risque élevé.
Tout est corrigé désormais. Voici le rapport de sécurité.
Nous avons aussi documenté les recommandations de l'ANSSI concernant l'authentification et la gestion des mots de passe, que Canaille implémente.
La plupart des recommandations sont implémentées, il reste principalement à supporter WebAuthn.
Documentation
Nous travaillons continuellement sur la documentation, et visons de suivre les recommandations de Diátaxis.
Nous avons écrit des chapitres pour le premier lancement de Canaille et la configuration du premier client OpenID Connect.
Ces premières étapes nous indirectement fait travailler sur pydantic-settings-export, qui permet notamment aux utilisateurs d'exporter un fichier de configuration avec toutes les valeurs par défaut commentées et décrites, ce qui offre un bon point de départ pour commencer à adapter la configuration. Nous utilisons encore une implémentation personnalisée, le temps de faire remonter toutes les modifications dont nous avons besoin dans le projet original.
La suite
Canaille vise la simplicité et son périmètre fonctionnel est donc assez restreint.
Nous limitons donc le nombre de fonctionnalités que nous souhaitons implémenter, cepedant il en reste quelques unes :
Le support de WebAuthn comme facteur d'authentification.
Cela nous permettra d'implémenter les dernières recommandations de l'ANSSI qui manquent.
Le support d'une méthode de Captcha.
Il est à première vue étonnant d'inclure cette fonctionnalité à l'heure où la pertinence des Captchas s'amoindrit avec l'apparition des IAs.
Nous notons cependant que c'est une fonctionnalité essentielles pour certains utilisateurs, comme en témoigne le comparatif très poussé de solutions de SSO libres publié par la Contre-Voie l'année dernière.
L'implémentation d'un système de greffons personnalisés pour Canaille.
C'est à un horizon plus lointain, mais nous aimerions proposer une API pour que des développeurs puissent implémenter leur propre facteur d'authentification pour Canaille, ou bien leur propre connecteur de base de données.
À par ces fonctionnalités visibles, l'essentiel des évolutions à venir viendra sous le capot :
L'amélioration de la pile SCIM, notamment pour apporter le support des filtres SCIM.
L'amélioration de la pile OIDC pour apporter le support de nouvelles normes.
Notamment celles qui ont a trait à la déconnexion centralisée ou bien à la sécurité.
