URL: https://linuxfr.org/users/serge_ss_paille/journaux/quelques-surprises-techniques-dans-pythran Title: Quelques surprises techniques dans Pythran Authors: serge_sans_paille Date: 2019年11月07日T07:51:39+01:00 License: CC By-SA Tags: python et pythran Score: 31 Demat' iNal, Il y a peu sortait la version 0.9.4 du compilateur [Pythran](https://pythran.readthedocs.io), délicatement appelée *Hollsent*. Pour rappel, Pythran est un compilateur pour du code scientifique écrit en Python, canal optimisation de performances. À cette occasion, en plus de l'habituelle [annonce sur la mliste de diffusion](https://www.freelists.org/post/pythran/Pythran-094-Hollsent), un petit [pot-pourri](http://serge-sans-paille.github.io/pythran-stories/pythran-094-hollsent.html) des améliorations techniques a été rédigé par votre serviteur. Et comme c'est quand même plus marrant d'écrire en français, en voici une traduction libre. C'est surprenant, mais il y a dans cette sortie des choses que je n'aurais jamais cru voir dans Pythran. Et surtout, c'est venu tout naturellement. Si si. Support (partiel) de ``isinstance(...)`` ======================================== Cet innocent bout de code est complètement valide en Python : ```python def abssqr(x): if isinstance(x, complex): return x.real ** 2 + x.imag ** 2 else: return abs(x) ** 2 ``` Mais il a longtemps été invalide en Pythran, à cause de la garde sur ``isinstance(...)``. Si on instanciait cette fonction sur un ``float``, on se payait une erreur comme quoi il n'y a pas de méthode ``real`` sur un nombre flottant. Ce genre de test que l'on pourrait résoudre lors de la compilation n'est pas sans rappeler le [if constexpr](https://en.cppreference.com/w/cpp/language/if) introduit en C++17. Et la construction syntaxique est assez proche d'un ``if x is None:``. Construction supportée par Pythran ! Après quelques détails techniques que je vous passe (mais dont vous pouvez avoir un avant goût avec ``pythran -P moncode.py``), liés au fait que Pythran utilise C++11 comme backend, on s'en sort très bien. Pour la blagounette, le code sus-cîté est de toute façon optimisé par Pythran sous la forme ``abs(x) ** 2`` qui est un motif connu et remplacé par un appel à un intrinsèque. Mais bon, c'est pour l'exemple. Support (incomplet) de ``type(...)`` ==================================== Encore une histoire de (sale) type. On sent que ce n'est pas ma tasse de thé... Et pourtant l'implémentation dans ``pythonic`` est d'une simplissime simplicité : ```c++ template typename type_functor::type type(T const &) { return {}; } ``` où ``type_functor`` fait juste une association entre un type et un foncteur permettant de générer des objets de ce type, du genre ```c++ template struct type_functor> { using type = functor::list; }; ``` Ce qui est fascinant, c'est que ``functor::list`` existait déjà dans Pythran, pour représenter le *builtin* ``list(...)``. Il se passe des choses... Grâce à ``type(...)`` on peut écrire de jolis codes polymorphes, avec des fonctions d'ordre supérieur, comme : ```python def poly(x, l): return type(x)(l) + x ``` Et ça passe crème dans Pythran, youhou. ``clang-cl.exe`` ================ Et oui, un ``.exe``. C'est fou ! En général, les extensions natives sous Windows sont compilées par le *Microsoft Visual Studio Compiler*. C'est même une obligation [codée en dur](https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Lib/distutils/msvc9compiler.py#L384) dans ``distutils`` (contrairement à Linux où l'on peut paramétrer assez facilement le compilateur utilisé). Et un des problèmes avec ce compilateur, c'est qu'il peine terriblement à compilé du C++11 un peu poilu, là où clang-3.5 et gcc-5 s'en sortent très bien... Et comme j'ai des utilisateurs Windows... Et bien en tirant profit de ``clang-cl.exe``, qui fournit une interface compatible avec ``cl.exe``, on peut enfin compiler du C++ moderne sous MS. Il y a bien eu besoin d'une petite [modification de singe](https://en.wikipedia.org/wiki/Monkey_patch) sur ``distutils``, mais une petite crasse est peu de chose à ce niveau... Et bien que l'approche ne soit pas officiellement compatible, **ça marche chez moi** enfin, sur [AppVeyor](https://ci.appveyor.com/project/serge-sans-paille/pythran/builds/28505845). Support de Python 3.8 ===================== La représentation interne de Pythran est proche de celle de l'[ast](https://docs.python.org/3/library/ast.html) Python, mais elle se doit d'être capable de représenter les différentes versions de dernier : py2, py35, py36, py37, py38. Un travail grandement facilité par l'existence du paquet [gast](https://github.com/serge-sans-paille/gast) dont je remercie chaleureusement l'auteur ! Comme prévu, cette bafouille est plus longue que la version anglaise, et beaucoup plus agréable pour moi à rédiger, en espérant qu'elle ait été agréable à lire !