PyParis 2017 — fin des inscriptions dans 10 jours

Posté par  (site web personnel) . Édité par ZeroHeure, Davy Defaud et Benoît Sibaud. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
16
1
juin
2017
Python

La conférence PyParis, qui fait suite à PyData Paris, aura lieu les 12 et 13 juin 2017 à La Défense. Plus de 300 personnes sont attendues. Si vous souhaitez participer, il est impératif de prendre vos billets avant le 9 juin. Le code promo LINUXFR4PY vous donnera 10 % de réduction.

Le programme est maintenant bouclé, avec trois cycles de présentations consacrés à l’analyse de données en Python :

  • Integrating and shaping data : gestion des données massives, intégration, analyses statistiques, exploration interactive, etc. ;
  • Learning, deep and wide : machine learning / deep learning ;
  • scikit-learn day : une journée entière consacrée à la bibliothèque scikit-learn dédiée au machine learning en Python, qui est développée en partie en France.

Et également :

  • quatre interventions plénières (keynotes) : les tendances du Web en Python, Jupyter, scikit-learn, Python dans l’éducation ;
  • Python Core : les dernières évolutions du langage Python et des outils qui vont bien autour ;
  • Web & Cloud : cadriciels et outils pour faire des applications Web en Python ;
  • Education : une journée de conférence sur l’utilisation de Python dans l’éducation (scolaire, universitaire ou hors système). Cette journée est gratuite pour les professionnels de l’enseignement et les membres des associations intervenant dans l’apprentissage du « code », sur présentation du code promo EPI4PY ;
  • 8 ateliers de 90 minutes ;
  • une session de lightning talks.

Aller plus loin

  • # Participer

    Posté par  . Évalué à 2.

    Merci pour l'info. Le contenu est intéressant.

    J'ai pas vu passer de dépêche ou journal ici concernant cette conf. Quel site / liste de discussion me conseillez-vous de suivre pour être averti plus tôt et envisager de présenter lors d'un évènement comme ça ?

    La question vaut pour les autres confs Python. Je crois que pour les PyCon, l'info est diffusée ici avant le bouclage du programme.

  • # Présentation cffi

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

    Bonjour tout le monde,

    J'ai été sélectionné pour présenter le module cffi réalisé par l'équipe de PyPy. Cffi permet de réaliser facilement des extensions Python. Si vous venez, passez me voir !

    Par contre, interdit de se moquer de mon magnifique accent Français, il paraît que c'est sexy ;-)

    JS

    • [^] # Re: Présentation cffi

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

      Cffi c'est pas à la mode, il faut faire du covfefe maintenant !

    • [^] # Re: Présentation cffi

      Posté par  . Évalué à 3. Dernière modification le 02 juin 2017 à 19:56.

      En deux mots, quels avantages par rapport à swig (si tu peux te permettre de compiler un .so) ou ctypes (si tu peux pas) ?

      • [^] # Re: Présentation cffi

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 06 juin 2017 à 11:01.

        Légèreté, simplicité.

        cffi est vraiment dédié Python alors que SWIG est plus généraliste.

        Par rapport à ctypes, tu n'as pas besoin de déclarer manuellement tes structs et fonctions, tu copies/colles ton header C et cffi se débrouille.

        Si je trouve le temps, je ferai un journal pour en parler.

      • [^] # Re: Présentation cffi

        Posté par  . Évalué à 2.

        cffi fonctionne grosso modo comme ctypes, mais avec une API différente. Selon les personnes, on préférera cffi ou ctypes (l'argument « il suffit de copier/coller les entêtes C » pour cffi est un peu simpliste : vu la complexité de certains entêtes, il faudra élaguer ou restructurer… par ailleurs, si on wrappe autre chose qu'une bibliothèque C, cela devient carrément un inconvénient).

        Comparé à swig ou Cython, cela n'a rien à voir : les premiers te compilent une extension C à l'avance, que tu peux ensuite distribuer. cffi et ctypes créent un wrapper au runtime. Cela a des avantages et des inconvénients : l'avantage est de ne pas nécessiter de distribuer une extension binaire séparée pour chaque plateforme ; l'inconvénient est de perdre facilement la sécurité du typage C (sécurité toute relative, certes), car les déclarations cffi ou ctypes peuvent très bien se retrouver désynchronisées avec la version installée de la bibliothèque externe (dit autrement : si cette bibliothèque ne garantit pas la même ABI d'une version sur l'autre, ton wrapper cfii ou ctypes peut être assez plantogène). Par ailleurs, cffi et ctypes peuvent avoir un surcoût non négligeable en performances.

Suivre le flux des commentaires

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