Blog entries

  • PyconFR 2014 : jour 1, BDD, postgresql et asyncio

    2014/11/03 by Arthur Lutz

    J'ai eu le plaisir de participer à la conférence PyconFR 2014, voici quelques notes sur les présentations auxquelles j'ai pu assister. Étant donné la longueur, je vais publier sous forme de plusieurs billets de blog.

    http://www.pycon.fr/2014_static/pyconfr/images/banner.png

    BDD avec Behave

    Le Behaviour Driven Develpment en Python peut se faire avec behave. Dans un premier temps on décrit en language "naturel" le test. Dans un deuxième temps on implémente les tests unitaires pour faire le lien avec la description behave, et on met les chaines de caractères dans un decorateur @given, puis @when puis @then.

    Les scenarios behave sont utiles pour le dévelopement, pour la documentation, pour la formation des nouveaux arrivants et même pour faciliter la supervision des applications en production.

    Les diapos de la présentation sont disponible sur slideshare.

    Python + PostgreSQL

    Stéphane Wirtle nous a présenté comment les relations étroites entre le monde de Python et celui de PostgreSQL.

    https://avatars1.githubusercontent.com/u/2947270?v=2&s=400

    Points à noter :

    • FDW : Foreign Data Wrapper, dont voici une liste sur le wiki de PostgreSQL
    • PL (Procedure Language) : PL/C, PL/Python, PL/v8, etc. pour étendre sa base de donnée. Les procedure language SQL sont par défault "trusted", les autres ne sont pas trusted par défaut. Dans CubicWeb, nous utilisons PL/Python pour la recherche plein texte et la lemmatisation du texte.

    Pour ceux qui souhaiteraient essayer un ORM, Stéphane Wirtle conseille Peewee ORM.

    Pour les migrations de schema SQLalchemy, Stéphane Wirtle nous conseille Alembic.

    Parfois un ORM peut générer beaucoup de requêtes SQL et il y a de la place pour une optimisation en tapant directement du SQL. Pour évaluer la surcharge dûe à l'ORM, on peut utiliser pgBadger.

    Support de présentation : https://speakerdeck.com/matrixise/python-and-postgresql-a-wonderful-wedding/

    Un serveur fiable avec python 3.4

    Après une petite introduction aux principes de concurrence, Martin Richard nous a présenté un retour d'expérience sur l'utilisation du module asyncio introduit dans python 3.4. Il permet de ne plus avoir à utiliser twisted ou gevent.

    Les ressources et bibliothèques qui utilisent asyncio sont recensées sur http://asyncio.org/

    objgraph permet de d'analyser des structures de données Python pour identifier des fuites memoire.

    memoryview introduit dans python3.4 permet de faire "référence" à une structure de données sans la copier, ce qui peut être très pratique mais rend complexe la gestion de code.

    Martin a utilisé @lru_cache pour mettre en cache les resultats d'un calcul en utilisant la politique de cache "Least Recently Used (LRU)".

    Support de présentation : http://marti.us/t/pyconfr-2014/


  • PyconFR 2014 : jour 1, frameworks web et gestion de source

    2014/11/04 by Arthur Lutz

    Suite de pyconfr 2014 jour 1 épisode 1.

    Performance des frameworks web : Python vs the world

    Ronan Amicel nous a présenté le travail de benchmark publié par TechEmpower. Ces tests et résultats sont forcement faux et biaisés, mais le code source des tests est publié en libre et il est donc possible d'apporter des corrections via le projet sur github

    Pour l'instant, Python3 serait plus lent que Python2, mais on peut espérer que Python3 rattrape son retard, puisqu'il est toujours développé. La comparaison avec pypy est surprenante, celui-ci est bien plus lent, l'hypothèse étant qu'il est ralenti lorsqu'il parle au driver mysql. En revanche, pour le test pypy + tornado, les performances peuvent être meilleures que nodejs car tornado est écrit en pur python il peut être optimisé par pypy.

    Dans le comparatif entre python et php, un acteur surprenant est phalcon qui a pris le parti de tout coder en C (plutôt qu'une partie seulement comme on peut le trouver dans nombre de projets python).

    Support de présentation : https://speakerdeck.com/ronnix/performance-des-frameworks-web-python-vs-the-world-v1-dot-1

    CubicWeb - Vos données ont du sens

    Nous attendions avec impatience cette présentation, et Christophe de Vienne a très bien présenté CubicWeb, le framework web dont Logilab est à l'origine.

    https://www.logilab.org/file/269991/raw/logo-cubicweb.png

    Après une courte introduction aux concepts du web sémantique (les URIS, les relations, le Linked Data), il a appuyé sur la nécéssité de donner du sens aux données que l'on stoque dans nos applications. Il a expliqué la finesse des réglages dans le moteur de permissions de CubicWeb.

    Il a expliqué certaines fonctionnalités intéressantes selon lui dans Cubicweb :

    • les hooks: équivalent des procédures stockées déclenchées par des triggers, ils sont écrits en Python et permettent de modifier des données en cascades, implémenter des règle de gestion ou générer des notifications.
    • les adaptateurs : permettent de maximiser la réutilisation de code en adaptant une entité à une nouvelle interface

    Selon Christophe, CubicWeb permet de développer une "base de donnée métier" strictement structurée, mais restant souple. Il a expliqué que l'interface par défaut n'est pas très sexy, mais qu'elle est néanmoins fonctionnelle comme backend d'édition.

    Une petite introduction aux cubes qui sont les "plugins" ou les "extensions" dans le monde CubicWeb, ils contiennent :

    • un schéma
    • du code métier
    • des vues
    • des contrôleurs

    Pour manipuler les données, CubicWeb utilise RQL, qui a été inventé avant SPARQL (langage de requête du web sémantique) et est plus pragmatique et lisible. Une fonctionnalité notable de RQL : plus besoin d'écrire des jointures SQL !

    Finalement Christophe a conclu en présentant le mariage de Pyramid et Cubicweb. Selon lui, en regardant dedans, ils ont des philosophies communes. Le code permettant de développer une application Pyramid sur une base CubicWeb est publié sur la forge de CubicWeb. Christophe a aussi expliqué qu'il pousse des modifications pour que CubicWeb soit plus accessible aux développeurs habitués aux modes de développement "à la python".

    Support de présentation : https://dl.dropboxusercontent.com/u/36590471/pyconfr-2014-pres-cubicweb/index.html

    La gestion de version, ce problème tellement simple…

    Pierre-Yves David (marmoute) nous a concocté un petit panorama des problèmes traités par les gestionnaires de source, avec des anecdotes de problèmes non-triviaux et quelques rappels historiques sur notre "science" informatique (merci les encodages!) Pierre-Yves s'est concentré sur les systèmes de gestion de version de "nouvelle génération", les outils décentralisés (hg, git, bzr). Forcément, étant donné qu'il travaille sur mercurial (et oui, celui écrit en python) il s'est concentré sur celui-là.

    http://mercurial.selenic.com/images/mercurial-logo.png

    Quand il travaillait chez Logilab, Pierre-Yves a notamment rajouté à Mercurial la notion de changeset obsolete et de phase pour faciliter la revue de code et le travail en équipe.

    Manipuler son code python avec RedBaron

    baron et RedBaron sont des projets assez prometteurs (et assez dingues) de manipulation de code en utilisant du code (plutôt que des éditeurs).

    Laurent Peuch est revenu sur les outils historiques du domaine : rope qui a pris la suite de bicycle repair man. Il y a aussi pyfmt par le même auteur, et autopep8 écrit par d'autres.

    Un exemple qui m'a parlé : ajouter @profile sur toutes les fonctions d'un script devient faisable en 3 lignes de python, et inversement pour les enlever. À suivre...

    Support de présentation : https://psycojoker.github.io/pyconfr-redbaron/presentation.html

    Prochain épisode

    Prochain épisode: jour 1, bus de communication, packaging et fin


  • PyconFR 2014 : jour 1, bus de communication, packaging et fin

    2014/11/04 by Arthur Lutz

    Suite à :

    XBUS

    Florent Aide nous a présenté son projet XBUS, un bus de communication pour les applications. L'idée est de gérer l'historique : pour faire parler des applications métier entre elles, on les connecte toutes au même bus. Dans certains cas, notamment quand la sécurité des données est en jeux, l'application qui traite le message renvoie un accusé de réception et de traitement (ACK).

    Côté technique, il s'agit de :

    • un cœur écrit en Go
    • zmq pour la communication
    • Python pour la logique

    Lors des questions un projet similaire a été mentionné : autobahn. Le projet XBUS est libre et publié sur bitbucket.

    Comment le packaging m'a simplifié la vie

    Étant donné qu'à Logilab, nous avons des avis assez arrêté sur les questions de packaging, je suis allé voir cette conférence.

    Xavier Ordoquy nous a présenté en détail virtualenv (pyvenv directement dans python à partir de 3.4) ainsi que l'outil pip.

    Historiquement pypi a été instable, mais la situation s'est améliorée depuis qu'il est sur un CDN. Il y a un travail en cours sur la sécurité (vérification d'intégrité, ssl obligatoire etc). devpi permet d'avoir un pypi en interne comme cache, mais aussi comme système de "staging" avant de publier sur le pypi "officiel".

    Selon Xavier, la guerre des distutils, python.packaging, distutils2, distribute, etc est finie. Il faut à présent utiliser setuptools et le connaître sur le bouts des doigts. Xavier nous recommande de copier un setup.py pour démarrer nos projets, par exemple celui de sentry.

    Côté numéro de version, il faut aller lire la PEP440 Version Identification and Dependency Specification.

    extra_requires permet de faire : pip install sentry[postgres] qui installe sentry mais aussi les dépendances pour le faire marcher avec PostgreSQL.

    Côté packaging, il va falloir selon Christophe apprendre à utiliser wheel et stevedore (code).

    Lors des questions, un membre du public mentionne le projet diecutter (docs, pypi).

    Support de présentation : https://speakerdeck.com/xordoquy/packaging-pratique-fr

    Autres liens collectés

    • Pour travailler sur les docstrings d'un projet python, pyment peut être utile.
    • fedmsg est un bus de communication utilisé chez fedora/redhat pour un grand nombre d'applications, il y a probablement de bonnes choses dedans. Il y a un début de travail sur un bus similaire chez debian

    Prochain épisode

    Prochain épisode: jour 2