Programme de la PyConFR 23

Posté par  . Édité par Benoît Sibaud, Pierre Jarillon et ted. Modéré par ted. Licence CC By‑SA.
19
3
fév.
2023
Python

La PyConFR, l'évènement de la communauté francophone du langage de programmation python, aura lieu du 16 au 19 février 2023 à Bordeaux. L'évènement est gratuit mais l'inscription au préalable est obligatoire.

PyConFR du 16 au 19 février à Bordeaux

Le programme vient de paraître, le sommaire des conférences, des ateliers et des sprints vous attend dans la suite de cette dépêche.

Voici le programme qui vient de paraître : (plus d'infos sur le site)

Conférences (Samedi et Dimanche)

  • CoWorks, a compositionnal microservices framework using Flask/AWS Lambda and Airflow
  • Développement VRAIMENT cross-platform avec Python
  • Portage Python sur Webassembly
  • Faire du Python professionnel
  • Python moderne et fonctionnel pour des logiciels robustes
  • Accessibilité numérique : faire sa part quand on est développeur·euse backend
  • Devenir incollable sur les callables !
  • Déployer du backend en 2023
  • « Fixed bugs » n’est peut-être pas le meilleur message de commit
  • Apport du langage Python dans un service de recherche hospitalière pour mener des analyses de deep learning
  • Documentation, logiciel libre et pérennité en arts numériques
  • Où il est question de gaufre et d’Internet
  • Garder le contrôle de ses données géolocalisées avant de les partager
  • Lutter contre le dérèglement climatique avec Django
  • sphinx-lint : un linter pour ta doc
  • Continuous performance analysis for Python
  • NucliaDB, une base de données pour le machine learning et les données non-structurées
  • Driving down the Memray lane - Profiling your data science work
  • Trying no GIL on scientific programming
  • Contribuer à l’open source sur des projets Python… sans coder
  • Fear the mutants. Love the mutants.
  • Running real-time machine learning analytics on traces
  • Python Côte d'Ivoire : Défis et Perspectives
  • Domain-driven design: what can Python do for you?
  • Supercharging Jupyter notebooks for effective storytelling
  • Rejoignez le Fediverse, ajoutez ActivityPub à votre site !
  • À la découverte de Polars (ou pourquoi vous pourriez quitter Pandas)
  • Introduction to Sigstore: cryptographic signatures made easier
  • Python for microcontrollers
  • Monorepo Python avec environnements de développement reproductibles et CI scalable
  • The power of AWS Chalice for quick serverless API development in Python
  • Giving and receiving great feedback through PRs
  • Uncovering Python’s surprises: a deep dive into gotchas
  • Python web performance 101: uncovering the root causes
  • From a Python script to an open-source project
  • Une bonne quantité de Python peut-elle rendre Firefox moins vulnérable aux supply chain attacks ?
  • Apprendre Python, c’est pour tout le monde en 2023 ! 💞
  • Cerveau, Biomarqueurs et Deep Learning
  • Apprentissage statistique adapté aux données sales avec dirty-cat
  • Let’s exploit pickle, and skops to the rescue!
  • Interactive HoloViz Visualization and Dashboards
  • Cloud infrastructure from Python code: how far could we go?
  • Traitement de données géographiques avec Rasterio, NumPy, Fiona et Shapely
  • REX analyse antivirus des fichiers de la plateforme emplois de l’inclusion
  • J'ai hacké ma chaudière pour avoir un thermostat !
  • Psycopg, troisième du nom
  • OCR : apprenez à extraire la substantifique moelle de vos documents scannés
  • Réinventer le tour du monde en (beaucoup) moins de 80 jours
  • Django Admin comme framework pour développer des outils internes
  • Geographic visualization using Streamlit
  • Transformez vos algorithmes de données/IA en applications web complètes en un rien de temps avec Taipy
  • Un membre très discret de la famille Jupyter mais pourtant si utile !
  • Interactive web pages with Django or Flask, without writing JavaScript
  • Je suis nul·le !
  • Monitorez vos applications Python (et pas uniquement votre infra)
  • Nua, un PaaS open source en Python pour l'auto-hébergement de vos applications
  • GEMSEO : une bibliothèque pour l’optimisation multi-disciplinaire
  • Save Sheldon: Sarcasm Detection for the Uninitiated!

Ateliers (Samedi et Dimanche)

  • Le Zen de Python appliqué à la production de jeux vidéo
  • Initiation à Django à travers la création d'un blog
  • Faire un module Tryton
  • Le réseau de neurones qui écrivait des romans
  • Comment créer des applications web de data science époustouflantes en Python - Tutoriel Taipy
  • Meme Saheb: using Dank Learning to generate original meme captions
  • Mettre le web en page(s) : générer un document PDF avec HTML et CSS

Sprints (Jeudi et Vendredi)

  • Traduction de la doc’ de Python en Français
  • Sprint sur le projet « Witness Angel »
  • Complete the work on Modoboa v2
  • Améliorer l'algorithme de détection de proximité de polygone pour l'étude du potentiel géothermique individuel (transition EnR)
  • Amélioration de ReservoirPy, un outil simple de Reservoir Computing
  • Developing community plugins for Argilla: an open-source platform for data-centric NLP
  • Improve tests for Zou/Kitsu API (Flask)
  • Sardine : improvisation musicale avec Python 3.10+
  • Développements de correctifs et tests des modules Ansible
  • Release d'AnyBlok 2.0.0
  • Rajout de fonctionnalités et créations de démos complètes et interactives pour Taipy

Aller plus loin

  • # Energie

    Posté par  (site web personnel) . Évalué à -3.

    Dommage que le programme soit déjà bouclé, j'aurais bien fait un speech sur l'efficacité énergétique catastrophique de Python, basé sur
    https://www.devsustainability.com/p/paper-notes-energy-efficiency-across-programming-languages

    En ces temps de crise énergétique et de réchauffement climatique, il est toujours bon de rappeler qu'un programme en Python consomme 30x plus d'énergie qu'un programme en Java… programme Java qui est déjà deux fois plus "consommateur" par rapport à des programmes écrits C ou Rust.

    • [^] # Re: Energie

      Posté par  . Évalué à 6.

      un programme en Python consomme 30x plus d'énergie qu'un programme en Java

      C'est seulement vrai si on oublie volontairement cython, numba, pythran, pypy, mypyc, …

      Pierre Augier et al. ont fait un papier intéressant à ce sujet ici et ici.

      Où on peut voir un même algorithme, implémenté en Python, tourner sur différents interpréteurs/jit/… et s'étaler très largement d'un ordre de grandeur plus performant que Java à un ordre de grandeur moins performant que Java.

      TL;DR :

      Our work shows that the performance of scientific programs depends less on languages than on the time spent on optimization and the developer skills to correctly use the right tools.

      • [^] # Re: Energie

        Posté par  (site web personnel) . Évalué à 3.

        Oui, en effet, en compilant du code Python en code natif avec ces outils, les voyants reviennent au vert.
        Ce qui m'inquiète le plus c'est le fait que tous les projets et les distributions que je vois passer, ainsi que la plupart des développeurs Python avec qui je peux échanger reste sur "l'interpréteur" standard, malgré souvent la connaissance d'alternatives.

        Java a également des outils pour avoir des exécutables natifs, mais la encore, on peut constater que quasi personne ne les utilise.

        Dommage qu'il n'y ai pas plus de communication à ce sujet sur le site officiel de Python ou lors des conférences.

        • [^] # Re: Energie

          Posté par  . Évalué à 4.

          Les développeurs Python délèguent aussi beaucoup aux librairies compilées comme Numpy ou Pandas.

          Après sur le plan écologique, il faudrait une analyse en cycle de vie plus poussé, car à mon avis le coup écologique du développement (et notamment du développeur) n'est pas négligeable. Et ça dans l'idée où l'on développe plus vite en Python qu'en Java.

          • [^] # Re: Energie

            Posté par  (site web personnel) . Évalué à -1.

            on développe plus vite en Python qu'en Java.

            J'aimerai savoir d'où ca sort… (a part d'un fort biais cognitif d'un développeur Python).

            • [^] # Re: Energie

              Posté par  . Évalué à -1.

              Sans le "demontrer", suffit de compter le nombre de lignes de code. Je crois me souvenir qu'il y a presque un facteur 5 en taille/LOC.

              J'avais trouvé un jour des taux de "buggitude" des différents langages de programmation, par ligne de code, et python était comparativement plus "buggé" mais comme il était beaucoup plus concis, il s'en sortait bien mieux. Ces taux de buggitude étaient par ailleurs assez semblable entre les languages, avec un écart assez faible.

              Certe les IDE modernes génèrent automatiquement le "boiler-plate" code pour java … mais ca reste du code à debugguer, et des bugs qui sont cachés dans des volumes plus importants.

        • [^] # Re: Energie

          Posté par  . Évalué à 2.

          Ces interpréteurs alternatifs sont peu documentés. Peux-on les utiliser absolument partout en remplacement de l'interpréteur standard ?

    • [^] # Re: Energie

      Posté par  (site web personnel) . Évalué à 7.

      J'aimerais bien qu'on arrête cette idée reçue de "Python contribue au réchauffement climatique".

      Une grande partie de l'industrie IT c'est du webdev (API, webapp, etc…) avec des backends qui communiquent avec des bases de données. C'est des workloads I/O bound, et non CPU bound. Cela signifie que l'application passe un temps significatif à attendre.

      Une autre grosse partie de l'industrie, c'est du data engineering/data science. Et la, les librairies sont développées en C/C++/Rust.

      Perso, je trouve que les pipelines de CI/CD qui lancent des builds de 15min pour chacun des 200 commits par jour fait sur chacun des 40 dépôts git de $BIG_BUSINESS_FOOBAR, c'est un peu plus problématique qu'une pauvre API Flask+SQLAlchemy qui tourne sur du AWS Lambda (qui ne lance le conteneur que quand il y a besoin de répondre à une requête IIRC).

      Surtout que j'ai vu pas mal de $BIG_BUSINESS_FOOBAR ne pas implémenter de cache pour leur CI/CD, donc chaque exécution de pipeline :

      • télécharge plus d'1GB de dépendance : le dossier target/ produit par cargo (Rust) pour Letlang fait 3.8GB, on en parle ?
      • n'utilise pas de système de build incrémental : sans ça, mon jeu C++ peut mettre jusqu'à 10min pour compiler entièrement, on en parle ?
      • mets tout ça dans une image docker (taggué au hash de commit) et la pousse dans un registry (consommation de bande passante), l'image docker n'est pas optimisée et fait jusqu'à 500MB, on en parle ?

      Pour troller un peu, ce genre de commentaire me fait penser au gouvernement qui te dit que c'est ta faute le réchauffement climatique car t'as pas débranché ta TV la nuit (les veilleuses ça consomme !!!!) alors que t'as des entreprises chinoise qui en un mois polluent plus que tout les pays de l'OTAN combiné (chiffres sortis de mon cul, pas besoin de fact check, c'est ce qu'on appelle une exagération).

      https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

      • [^] # Re: Energie

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 05 février 2023 à 19:34.

        Tu as raison d'évoquer les travers des systèmes d'intégration, de compilation ou encore la paresse qui fait dire à certain qu'on est pas à 1Go près ni à 10ms près.

        J'ajouterais à cette liste, les requêtes SQL inutiles/trop larges, les accès disques non cachés et la faible appétence à essayer d'optimiser quoique ce soit, sous prétexte que "c'est les autres le problème".

        Il n'empêche que ce n'est pas une raison pour ignorer les problèmes liés à l'utilisation de certains langages (PHP, Lua, Ruby, Perl, Python…).

        Si tu considères que la majorité des applications écrites dans ces langages passent leur temps à attendre (un top sur certains de mes serveurs tendent à prouver que non, mais bon, pourquoi pas l'envisager), utiliser un langage deux fois plus efficient permet de faire tourner deux fois plus de ces applications "patientes" sur un même serveur,
        donc mécaniquement de diminuer le nombre de serveurs (on parle de centaines de millions, 3% de la consommation électrique mondiale).

        • [^] # Re: Energie

          Posté par  (site web personnel) . Évalué à 2.

          De plus, on associe souvent le python avec numpy et consorts. Or oui ils sont très utilisés pour du calcul scientifique, mais bon il n'y a pas que du calcul pour les pubs dans la vie ^
          Quand tu fais un programme plus "standard" avec des vrais objets, là Python, bah… c'est pas la joie côté perfs.

          Ensuite on a heureusement désormais accès à des langages performants et moins verbeux ou traitres (oui je vous cible Java et c++ :) ) qu'à une époque.

          Si par exemple je devais recommencer Shinken aujourd'hui, c'est pas en Python qu'il serait codé :p

  • # Capture vidéo des interventions

    Posté par  . Évalué à 5.

    Bonjour,

    il y aura-t-il une capture vidéo des conférences ? et leur mise en ligne ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.