MakeMake The Dwarf Planet is a feed agregator.

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

by paugier from AFPy discuss

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

6 messages - 3 participant(e)s

Lire le sujet en entier

Lire la suite…

[Clermont-Ferrand] Meetup mercredi 26 nov 18h30

by drigaudie from AFPy discuss

Hello,

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

Au plaisir de vous rencontrer

Meetup Quizz

2025-11-26 18:30 (Europe/Paris) → 2025-11-26 22:00 (Europe/Paris)

3 messages - 3 participant(e)s

Lire le sujet en entier

Lire la suite…

S'abonner au Discourse via ActivityPub

by mdk from AFPy discuss

Les catégories du Discourse sont accessible via ActivityPub :

Vous pouvez vous abonner avec vos clients préférés (oui c’est un peu vide pour le moment) j’ai mis des liens mamot juste pour l’exemple.

Par exemple, voici ce post sur mamot.fr : Mamot - Le Mastodon de La Quadrature du Net

2 messages - 2 participant(e)s

Lire le sujet en entier

Lire la suite…

Le dogme SESE : « Un seul return par fonction »

by mdk from AFPy discuss

Bonjour les gens,

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 :

  • MISRA a dit que
  • L’IEC 61508 a dit que.
  • Dijkstra a dit que, rep à ça !
  • Ç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.

Plus de lecture

7 messages - 6 participant(e)s

Lire le sujet en entier

Lire la suite…

Canaille passe en version bêta

by Éloi Rivard <eloi@yaal.coop> from Yaal

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.

Canaille OIDC certification

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 :

Lire la suite…

Canaille beta is out

by Éloi Rivard <eloi@yaal.coop> from Yaal

Our recent work on Canaille funded by NLNet Foundation brings us to release a beta version. Let's have a look on what changed.

Recent Work

Task Manager

We implemented a task manager that allows Canaille to perform long-running tasks asynchronously. This is notably used to propagate SCIM requests or send emails. The implementation uses dramatiq, and we published the dramatiq-eager-broker package which allows maintaining synchronous behavior in the test suite, and when the task manager is not configured.

OpenID Connect Certification

As we mentioned recently, Canaille obtained OpenID Connect Foundation certification last September. This guarantees that Canaille behaves in compliance with most common OpenID Connect operations.

Canaille OIDC certification

The certification process revealed many interpretation errors, often minor but sometimes significant. We fixed most issues directly in Authlib, the underlying library implementing the standards.

Security

We implemented the remaining recommendations from the Radically Open Security audit. Most were minor recommendations following best practices, but there was a high threat finding. Now everything is now in place. You can have a look at the report. We also documented the ANSSI recommendations regarding authentication and password management, which Canaille implements. Most recommendations are implemented, the main remaining task is to support WebAuthn.

Documentation

We continuously work on documentation, aiming to follow Diátaxis recommendations. We wrote chapters for getting started with Canaille and configuring the first OpenID Connect client. These initial steps indirectly led us to work on pydantic-settings-export, which notably allows users to export a configuration file with all default values commented and described, providing a good starting point to begin adapting the configuration. We're still using a custom implementation while we upstream all the changes we need to the original project.

What's Next

Canaille aims for simplicity and its functional scope is therefore quite limited. We thus limit the number of features we want to implement, however a few remain:

  • WebAuthn support as an authentication factor. This will allow us to implement the last missing ANSSI recommendations.
  • Captcha method support. At first glance it's surprising to include this feature at a time when the relevance of Captchas is diminishing with the emergence of AIs. However, we note that this is an essential feature for some users, as evidenced by the very thorough comparison of open source SSO solutions published by La Contre-Voie last year.
  • Implementation of a custom plugin system for Canaille. This is on a more distant horizon, but we would like to offer an API so developers can implement their own authentication factor for Canaille, or their own database connector.

Besides these visible features, most upcoming developments will be under the hood:

Lire la suite…