Journal PyConfr2017 - Boudu !

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
20
26
sept.
2017

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 pour m'avoir permi d'aller à cette conf, et un spécial merci à @VictorStinner pour sa patience.

Les Aventuriers du Packaging Perdu

lien vers le résumé

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.
  • Petite piqûre de rappel sur le schéma de version utilisé dans Python PEP440. 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 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 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é

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 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) 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
  • Les annotations de type, qui faisaient l'objet de mon exposé, 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, 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 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 :

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é :

_: print((list(map(_.append, map(chr, [104,101,108,108,111]))),\n", "".join(_))[1]) = []

  • # Tout n'est pas rose malgré la ville

    Posté par  . Évalué à 10.

    Mention spéciale à l'irrespect involontaire de beaucoup d'auditeur.

    Involontaire, mais bien réel. Ces gens qui sortent d'un talk super en A001 sur un sujet qui les passionnent, qui changent de salle pour aller assister à une autre en A002, et qui rentrent dans la salle sans attendre que la conf précédente soit fini. Se disant oui mais je ne fais pas de bruit.

    Seulement bruit de portes + bruits de pas (oui 15-20 personnes qui rentre dans une salle même en faisant gaffe ça fait du bruit) + bruit de grincement des sièges qu'il faut "déplier" + l'absence de micro = Grosse gène.

    Ce n'est pas facile pour des conférenciers de parler super fort, surtout quand ces derniers ne sont pas maître de l'exercice. Alors, tous ces gens qui font du bruit, rendent difficile d'entendre la conclusion ou les questions.
    Ça coute quoi d'attendre la fin de la conf pour rentrer ?
    Ces personnes sont si égoïstes qu'elles se disent si le sujet les intéressent pas c'est pareil pour ceux qui sont déjà dans la salle ?

    Encore en B00 il y avait un micro, c'est dérangeant de voir des gens rentrer, ça perturbe, mais au moins on entend.

    J'envisage très sérieusement de venir avec des affiches l'année prochaine, style

    Merci d'attendre la fin pour rentrer, respectez les conférenciers et auditeurs.

    Excusez mon ton un peu acerbe, mais ça m'a gâché la fin de plusieurs confs, j'ai trouvé cela insupportable.
    Je me suis dit qu'en parler ici aidera à un peu à ne pas reproduire cette situation.

  • # Je rougis

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 26 septembre 2017 à 20:34.

    Merci serge_ans_paille pour ta critique du talk "Les Aventuriers du Packaging Perdu" dont j'étais un des présentateurs.

    Content que tu, parmi d'autres, aies appris quelque chose. Note que c'est également le cas pour nous qui avons découvert certaines choses lors de la préparation.

    Quant à ta conclusion sur notre humour… content également de n'avoir pas trop fait de flops :)

    Bref, merci. Je rougis.

  • # Les perfs c'est la vie

    Posté par  . Évalué à 4.

    Merci serge_sans_paille pour ton billet!

    On as mis en ligne les slides de notre présentation sur les tests de performances, elles sont ici: https://octobus.net/presentations/perf_test.html#/

    On espère avoir été intéressant, ce n'est malheureusement pas un sujet présenté très fréquemment malheureusement.

    Longue vie à Python et aux Tests!

  • # version généraliste du générateur de code de cpython

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

    En fait, l'outil ayant inspiré le générateur de code de cpython et dont le générateur de cpython n'est qu'une version spécifique à la tache est: https://nedbatchelder.com/code/cog/ C'est du bon mangez en!

    Exemple tiré de la documentation (basique pour comprendre comment ca marche:

    Vous écrivez ce code source

    // This is my C++ file.
...
/*[[[cog
import cog
fnames = ['DoSomething', 'DoAnotherThing', 'DoLastThing']
for fn in fnames:
    cog.outl("void %s();" % fn)
]]]*/
//[[[end]]]
...

    Vous le faites passé à la moulinette cog et ca donne ca: 

    // This is my C++ file.
...
/*[[[cog
import cog
fnames = ['DoSomething', 'DoAnotherThing', 'DoLastThing']
for fn in fnames:
    cog.outl("void %s();" % fn)
]]]*/
void DoSomething();
void DoAnotherThing();
void DoLastThing();
//[[[end]]]
...

    Et vous pouvez à nouveau modifier le code source python et repasser a la moulinette pour regénérer au sein du même fichier le code source.

    L'idée de base est que le code généré est le le code générant sont gardés dans le même source

  • # Slides du talk sur le packaging

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

    Les slides de notre talk sur le packaging sont maintenant en ligne

    https://twidi.github.io/python-packaging-talk/fr

Suivre le flux des commentaires

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