Sur Lyon − Meetup le 31 juillet
by grewn0uille from AFPy discuss
Hello,
Prochain meetup Python à Lyon : jeudi 31 juillet à partir de 18h au Malting Pot Part-Dieu !
Pour les sessions de l’été, pas de présentation au programme, mais des rencontres informelles 
2025-07-31 18:00 (Europe/Paris) → 2025-07-31 22:00 (Europe/Paris)
1 message - 1 participant(e)
Atelier en ligne (en anglais) pour apprendre à proposer une conf <3 (PyLadiesCon)
by Mindiell from AFPy discuss
Join our free online CFP workshop to craft a great proposal! 
Ca peut intéresser des gens je pense ;o)
1 message - 1 participant(e)
AFPy
by AFPy - Mastodon from AFPy - Mastodon
Only 6 days until the end of the Call for Proposals open until July 20, 2025 inclusive for PyConFR 2025 taking place from October 30 to November 2, 2025.AFPy
by AFPy - Mastodon from AFPy - Mastodon
Plus que 6 jours avant la fin du Call for proposals ouvert jusqu'au 20 juillet 2025 inclus pour la PyConFR 2025 se déroulant du 30 octobre au 2 novembre 2025Python 3.14 : découvrez les nouvelles fonctionnalités
by Camille Roux from Human coders
Python 3.14 entre en phase beta et apporte son lot de nouveautés ! Explorez les changements majeurs et les améliorations qui seront disponibles dans cette prochaine version du langage de programmation. Un aperçu essentiel pour les développeur·se·s Python qui souhaitent rester à jour avec les dernières évolutions du langage.
Commentaires
L'article Python 3.14 : découvrez les nouvelles fonctionnalités a été posté dans la catégorie Python de Human Coders News
__init__.py vide ou pas
by fcodvpt from AFPy discuss
bonjour,
Sur un projet existant que je rejoins, le fichier __init__.py contient l’import des différents modules.
D’après mes ressources, il serait préférable de laisser le __init__.py vide :
-
C’est ce que l’on trouve dans le Hitchhiker’s Guide
-
Et dans cette vidéo de Brandon Rhodes à la conférence code::dive 2019 : When Python Practices Go Wrong (44e minute)
Voici ce qu’il dit :
__init__.pyis a cost in the way of all the other modules that you might want to import.Worse yet, for convenience, some
__init__.pyfiles import all their package’s module. That’s ruining the ability to cherry pick one thing you want. You can’t touch the package without waiting to load everything inside of it.My advice, which is not what everyone would say, is to keep
__init__.pyempty of codeI do understand that my users don’t want to have to import things manually from all dozen of my modules, so I have “an API module” that import all of the important classes so that you can say :
from skyfield.api import xxx, yyy, zzz
J’ai retrouvé le fichier où il met ses imports : python-skyfield/skyfield/api.py at master · skyfielders/python-skyfield · GitHub
- Cependant, un article très récent de RealPython propose exactement l’inverse. Est-ce qu’il y a des choses qui auraient changé ?
Quel est votre avis ?
Je préfèrerai partir sur un __init__.py vide et cela m’intéresse de mettre les éventuels imports dans un fichier à part mais j’ai peur que ça me mette le bazar pour la documentation Sphinx (et sphinx-apidoc mais je vois un exclude pattern)
Merci d’avance pour vos conseils.
Françoise
14 messages - 7 participant(e)s
refonte mobilizon instances
by steph1978 from Linuxfr.org
Sommaire
Ce journal raconte la ré-écriture de l'outil Mobilizon Instances suite au passage de témoin entre Framasoft et Kaihuri.
Mobilizon Instances est outil satellite de Mobilizon, l'outil de gestion d'événements pour le Fediverse. Il s'agit du catalogue des instances que les utilisateurs ont bien voulu référencer (optin). Cela permet aux nouveaux venus de trouver une instance qui pourrait correspondre à leurs goûts.
Mobilizon Instances récolte aussi des données statistiques sur ces instances, quotidiennement, afin de les exposer.
Pourquoi
Mais cet outil existe, tourne et son code est publié, pourquoi vouloir le ré-écrire, me direz vous ?
Soyons honnête : parce que j'en ai envie ! Mais cette envie est quand même motivée par certaines raisons liées à la maintenabilité et à l'évolutivité. Car je serai probablement le seul à y toucher. Les contributeurs sont toujours bienvenus mais nous préférons concentrer les efforts sur le produit principale.
Les raisons
Nodejs 8 ; le code n'a pas été retouché depuis des années et quand j'ai essayé de le faire tourner localement, je n'y suis pas arrivé. Soit je passe du temps à le mettre à niveau, soit j’investis ce temps dans autre chose
Nodejs ; je n'aime pas écrire du JS/TS, encore moins en backend. Je vois l'intérêt d'un framework web quand on a un front chiadé ; nous utilisons vuejs pour Mobilizon. Ici, le cas me paraît suffisamment simple pour s'en passer. Pour le backend, j'aime beaucoup Elixir ou Python, un peu Go, un jour peut être Rust.
Sqlpage ; j'ai déjà eu deux bonnes expériences avec SQLPage sur des projets perso. Quand on peut se permettre de rester proche des données et qu'on aime pas le frontend, c'est assez idéale. Je voulais mettre à profit cet avantage pour le cas présent.
Quand je parle de bonne expérience, je parle autant des fonctionnalités de l'outil que de sa superbe documentation et de sa bienveillante communauté. Je ne crois pas être seul.
Design
Le besoin est simple : deux écrans de consultation (liste, statistiques), un formulaire pour la proposition de nouvelle instance, et une tâche planifiée pour collecter et mettre à jour les données statistiques.
exploration
L'auteur de sqlpage est toujours disponible pour une discussion sur son produit, pour peu qu'on lui amène un cas d'usage concret.
Et cette discussion confirme mon intuition : sqlpage ne gère pas et n'a pas vocation à gérer des tâches planifiées.
J'ai donc un petit dilemme: si je dois écrire une bonne partie du logiciel avec une autre solution, pourquoi ne pas l'écrire entièrement avec cette autre solution.
Je me lance un court moment dans l'écriture du premier écran - liste des instances - en python+fastapi+pypug. Pypug en particulier, est très sympa quand on préfère une représentation à la Yaml plutôt qu'à la XML. Nous utilisons Pug dans le Mobilizon Importer.
Mais je ne trouve pas la foi d'écrire tout le code nécessaire à la simple représentation du contenu d'une table SQLite dans un tableau HTML : template avec itération, route web, DAO pour lire les données ; alors que je sais que SQLPage le fait en quelques lignes.
Stack
J'ai choisi:
- Sqlpage pour les pages web
- SQLite pour la base de données
- Python+scrapy pour la collecte des informations
- Crond (alpine) pour l'ordonnancement des tâches
- s6 pour la gestion des services
- healthcheck.io pour l'observabilité
- le tout empaqueté dans une image docker
Productivité
Temps
J'ai donc balancé tout ça dans un LLM et deux minutes plus tard … Non, je n'ai pas fait ça.
Mais, une fois n'est pas coutume, j'ai comptabilisé le temps que j'y ai passé. Je voulais me prouver que je ne passais pas plus de temps sur une ré-écriture que sur une remise à niveau.
Cela donne:
- design (1h) : le choix de la stack, le mise en place du projet, l’exploration
- import data (4h) : j'ai perdu trop de temps sur des données Json, se méfier de
->versus->>en SQL - écrans (4h) : efficace, avec les composants table et chart, sans surprise
- tâche planifiée (4h) : scrapy est top, vraiment peu de code à écrire, sans surprise
- packaging (3h) : peaufiner un dockerfile prend toujours un peu de temps car il faut tester
- déploiement (1h) : idem pour un docker compose
- optimisation (4h) : la vue statistiques était trop lente à mon goût, j'ai refactoré
Au total 21h, réparties sur une semaine et demie. Vous me direz ce que vous en pensez. Moi je trouve cela très correct.
Lignes de code
Autre indicateur qui m'intéressait, la quantité de code dans l'optique, le moins à maintenir, le mieux. Ça veut dire déléguer une partie de la complexité aux dépendances ; c'est le but.
- vue : 93 lignes de SQL
- job : 157 lignes de python, dont 41 liée à la migration de système
- glu : 119 lignes de shell, dont 49 liée à la migration de système
Soit 369 lignes de code, 279 si l'on ne prend pas en compte le code nécessaire à la transition depuis le système existant. À comparer aux 1737 lignes de code actuelle.
Ce chiffre est à prendre avec des pincettes car minimiser la quantité de code est un objectif qui me tient à cœur mais qui n'est pas forcément partagé. Et il manque encore des choses, qui vont venir faire augmenter ce chiffre.
J'attribue ces bons résultats - temps passé et quantité de code - au choix de la stack et à la bonne connaissance que j’en ai.
La stack prend en charge une bonne partie du travail à faire : Sqlpage pour la gestion des routes et la production du HTML+CSS+JS. Scrapy pour la gestion du parallélisme, du protocole HTTP et des ré-essais. Sans oublier s6 pour la gestion des services au sein du container.
Futur
Cette version réécrite va tourner quelques temps en parallèle de la version en production, avant une éventuelle bascule.
La vue liste mérite entre temps d'être peaufinée, avec probablement l'ajout d'un peu de styles.
Je dois aussi travailler sur le nettoyage des instances fantômes et optout, géré les défauts de réponse.
À ce stade, j'ai trouvé l'exercice très plaisant.
Hep! pas si vite ! et le code alors ?
Il est consultable ici.
Commentaires : voir le flux Atom ouvrir dans le navigateur