MakeMake The Dwarf Planet is a feed agregator.

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

1 message - 1 participant(e)

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 tout est là désormais. 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 everything is now in place. 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…

Libusb-UVC : une bibliothèque Python pure pour les caméras USB Video Class

by freejeff from Linuxfr.org

Le protocole UVC (USB Video Class) définit la façon dont une caméra expose ses flux vidéo et ses contrôles à travers l’USB.
Il s’agit d’un protocole standardisé par l’USB-IF, utilisé par la quasi-totalité des webcams modernes : caméras internes de portables, modules USB, microscopes numériques, etc.
Sur Linux, c’est habituellement le module noyau uvcvideo qui gère ces périphériques et fournit une interface /dev/video* à travers V4L2.

Mais dans certains cas, on a besoin d’un accès plus bas-niveau, directement via libusb :
pour expérimenter des contrôles propriétaires, récupérer des images fixes (still image capture), inspecter les descripteurs, ou encore gérer des flux compressés que V4L2 ne supporte pas encore (H.265, VP8, AV1…).

C’est dans ce contexte qu’est née Libusb-UVC.

Objectif du projet

Libusb-UVC vise à fournir une implémentation Python pure du protocole UVC :

  • indépendante du pilote noyau (uvcvideo peut rester chargé),
  • pilotable entièrement en espace utilisateur via libusb,
  • avec une API orientée objet et un outillage d’inspection complet.

Le but n’est pas de remplacer V4L2, mais de comprendre et explorer le protocole depuis l’espace utilisateur, pour le contrôle, le streaming et l’expérimentation.

Ce que fait la bibliothèque aujourd’hui

  • Streaming complet en userspace
    Le module gère les flux YUYV et MJPEG en temps réel, avec reconstruction des trames, gestion de l’isochronisme et du changement d’alt-setting.
    Les flux compressés (H.264, H.265, VPx, AV1…) sont également pris en charge en mode pass-through : la bibliothèque ne les décode pas, mais fournit les paquets bruts aux décodeurs en espace utilisateur (par exemple PyAV ou GStreamer).

  • Contrôles vidéo complets (VC)
    Les unités standard (Input Terminal, Processing Unit) et les Extension Units propriétaires sont découvertes dynamiquement et peuvent être interrogées ou modifiées (GET_CUR, SET_CUR, etc.).
    Un système de fichiers quirks JSON permet de documenter les GUIDs connus et de donner des noms explicites aux sélecteurs (par exemple les GUID Quanta ou Microsoft XU).

  • Gestion des images fixes (Still Image Capture)
    Le protocole UVC 1.1 introduit la possibilité pour une caméra de capturer une image unique à la demande, avec éventuellement une résolution différente du flux vidéo.
    Cette fonctionnalité a été implémentée : la bibliothèque sait envoyer la commande STILL_IMAGE_TRIGGER et récupérer la trame correspondante.
    En pratique, aucune caméra testée jusqu’ici ne semble exposer de vrai mode still image, même si beaucoup déclarent les descripteurs correspondants.
    Cela reste donc surtout une partie exploratoire du protocole, mais elle est fonctionnelle côté code.

  • Mode hybride avec le pilote du noyau
    Si uvcvideo est chargé, la bibliothèque peut détacher uniquement l’interface de contrôle (VC) pour lire ou écrire les paramètres sans perturber les applications utilisant /dev/video*.
    Le flux vidéo reste alors accessible via les outils classiques, ce qui permet un diagnostic fin sans avoir à décharger de module.

  • Inspection et génération de profils (quirks)
    L’outil pyusb_uvc_info.py permet d’afficher toutes les interfaces, formats, résolutions et contrôles d’une caméra.
    Il peut aussi générer un fichier JSON décrivant la structure de ses XU, utile pour la documentation ou le débogage.

Particularités et différences avec pyuvc

Contrairement à pyuvc (qui repose sur le pilote V4L2 et sur libjpeg-turbo pour le décodage MJPEG),
Libusb-UVC ne s’appuie sur aucun pilote noyau.
Tout est géré via les transferts USB, en Python pur, ce qui permet de manipuler des flux que V4L2 ignore encore (par exemple des flux compressés modernes).

Pour le décodage, la bibliothèque peut déléguer à :

  • PyAV (binding FFmpeg) pour le décodage logiciel ou matériel,
  • GStreamer (via appsrc) pour des pipelines plus complexes, tout en restant agnostique sur le backend.

Ce choix rend la bibliothèque beaucoup plus flexible que pyuvc, notamment pour des usages d’analyse ou de recherche.

Perspectives

Les prochaines étapes concernent :

  • la validation de nouveaux GUIDs d’Extension Units (Quanta, Realtek, Microsoft),
  • et la consolidation de la documentation technique (schémas des descripteurs, exemples de commandes GET_LEN et GET_INFO).

Avec Libusb-UVC, on a un outil libre et reproductible pour explorer le protocole UVC, comprendre les caméras, et permettre à d’autres de bâtir dessus.

Code et documentation

  • Code source : github.com/jeffwitz/Libusb-UVC
  • Licence : MIT
  • Langage : Python ≥ 3.8
  • Dépendance principale : libusb1
  • Exemples fournis : inspection, capture d’image, capture vidéo, génération de quirks

Conclusion

Libusb-UVC offre un regard complet sur le protocole UVC depuis l’espace utilisateur.
C’est un outil utile pour les chercheurs, makers ou développeurs qui veulent comprendre comment une caméra dialogue réellement sur le bus USB —
et un bon point de départ pour aller au-delà de ce que propose V4L2.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Lire la suite…