URL: https://linuxfr.org/users/serge_ss_paille/journaux/pyconfr2017-boudu Title: PyConfr2017 - Boudu ! Authors: serge_sans_paille Date: 2017年09月26日T11:20:42+02:00 License: CC By-SA Tags: pyconfr et python Score: 20 PyconFr, tu viens pour les talks et tu te retrouves à apprendre plein de trucs en discutant avec les uns et les autres. Et puis entre les anciens étudiants, les core devs Python ou Mercurial, il y avait du beau monde et **plein** de trucs à apprendre. Hop aperçu non exhaustif des deux sujets qui m'ont marqués (ce qui n'enlève évidement aucun intérêt aux autres sujets). Mais avant ça merci à [Quarkslab](https://www.quarkslab.com/) pour m'avoir permi d'aller à cette conf, et un spécial merci à [@VictorStinner](https://twitter.com/VictorStinner) pour sa patience. Les Aventuriers du Packaging Perdu ================================== [lien vers le résumé](https://www.pycon.fr/2017/programme.html#les-aventuriers-du-packaging-perdu) Honnêtement, je partais sceptique sur cette conf, pensant avoir suffisament roulé ma bosse sur le sujet. Mais j'ai découvert pleins de trucs ! - La possibilité de migrer une partie des infos présentent dans le ``setup.py`` vers le ``setup.cfg``, on en apprend bien sur plus en lisant la [doc sur le setup.cfg](https://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files). - Petite piqûre de rappel sur le schéma de version utilisé dans Python [PEP440](https://www.python.org/dev/peps/pep-0440/). On notera le suffix ``post0`` pour les petits patchs en douce post release et le suffix ``dev`` pour... les versions de dev. - Découverte du paquet [twine](https://pypi.python.org/pypi/twine) qui corrige certains soucis de sécurité (entre autre) liés à ``python setup.py sdist upload``. - Découverte de la version test de pypi, qui permet de tester l'upload d'un projet sans que ce soit visible par la version officielle (``twine upload -r test``) - Découverte de l'initiative [manylinux](https://github.com/pypa/manylinux) qui vise à faciliter la construction de wheel portable. Ça passe par des images docker basées sur CentOS, ce qui semble une bonne idée. L'humour de la présentation était goûtu « Did you ever metadata you didn't like? », « parce que c'est notre projet »... J'ai ri. Tester les performances, pourquoi et comment ? ============================================== [lien vers le résumé](https://www.pycon.fr/2017/programme.html#retour-dexperience-sur-la-mise-en-place-dune-machi) Argumentaire très intéressant comme quoi les performances sont une fonctionnalité comme une autre du code, qu'elles font partie de l'expérience utilisateur. Et qu'elles méritent leurs tests. Parmi tous les problèmes rencontrés, on compte la reproductibilité, le besoin d'un historique pour détecter les changements... Une remarque qui m'a bien plue : penser à séparer la partition sur laquelle s'exécute les benchmarks du reste, pour éviter les effets de bords. L'outil utilisé pour gérer la collecte des benchmarks s'appelle [asv](http://asv.readthedocs.io/en/latest/index.html) et pour attaquer en mode force brute le problème de la reproductibilité, une machine dédiée a fait l'affaire ! Et c'est dans tout, c'que je n'dis pas, que tu te reconnaitras ============================================================== Les discussions de traverses et certains exposés m'ont donné des idées / éveiller à de nouveaux concepts, alors je les refourgue, tel un margoulin (cc [@wisk](https://twitter.com/wiskitki)) ici. - CPython utilise un script interne basé sur des annotations dans des commentaires autour de certains builtins C pour harmoniser la documentation, et optimiser l'*unboxing* des arguments. Vive le code généré ! - Dans CPython, plusieurs fichiers générés (genre le ``./configure`` ou ceux générés par la fonctionnalité ci-dessus) sont stockés dans le dépôt git, avec un *hook* de commit qui s'assure qu'ils soient à jour. - Une sorte d'annuaire à l'ancienne de softs Python [une taxonomy python](https://pythonlinks.info/) - Les annotations de type, qui faisaient l'objet de [mon exposé](https://www.pycon.fr/2017/programme.html#linterpreteur-python-quel-sale-type), sont utiles à des projets comme moyen de documentation, et pour permettre de vérifier que l'interface des plugins est bien respectée. - L'idée d'avoir des tests de non-regression de performance en normalisant par rapport à une référence calculée dynamiquement. Dans le cadre de [pythran](https://pythonhosted.org/pythran/), on pourrait par exemple vérifier que le code généré va ``k`` fois plus vite que le code numpy, mais ça reste dépendant de la version du compilo etc, donc la fenêtre de test risque d'être assez lâche. - Quand on habite dans le sud de la france, on peut avoir des scorpions en liberté dans son jardin o_O - la [réponse officielle](https://mail.python.org/pipermail/security-announce/2017-September/000000.html) au problème de typosquatting dans PyPi, super bien documentée ! Concernant les annotations de type, j'ai bien aimé la question qui demandait comment documenter le type de retour de la fonction suivante : ```python def foo(n: int): class SomeTypeDependingOnN(object): some_attr: int = n return SomeTypeDependingOnN ``` Qui est une sorte de meta-classe du pauvre. Et bien ça parait compliqué vu que le type est local à la fonction :-) Et hop, cadeau, le petit code utilisé pour introduire mon exposé : ```python _: print((list(map(_.append, map(chr, [104,101,108,108,111]))),\n", "".join(_))[1]) = [] ```

AltStyle によって変換されたページ (->オリジナル) /