Python Connaissez-vous Cython ? - Page 1

Je viens de regarder cette petite présentation de Cython.
En deux mots, il s'agit de compiler du Python en C, ou plus exactement de transformer le code Python en C, qui sera compilé avec un compilo standard.
Si on connaît le type des variables, on peut les typer afin de faciliter le boulot du compilateur et donc d'augmenter les perfs.

Ils annoncent tout de même des facteurs entre 2 et 1 000 (!), c'est plutôt pas mal Sur des exemples simples (Fibonacci), il y a même du Cython plus rapide que le C.

Je n'ai pas encore joué avec, mais je sens que ça ne va pas tarder ^^
Avez-vous déjà essayé ?

Je me demande ce que donnerait une version de Python (ou d'un autre langage du même type) interprétée, comme actuellement, mais avec le rajout du typage fort...

Ça me ferait rire que les gens se rendent compte d'un coup que ce qui plombe les perfs de ces langages, c'est le typage dynamique tant vanté par certains

Je suis du même avis : c'est génial, quand on prend un langage dynamique et interprété, qu'on ajoute du typage fort et qu'on le compile, on gagne en performances. Prodigieux

Mais du coup à moins de préférer la syntaxe du Python, on avait pas franchement besoin de faire un 360° pour en revenir à ce point-là ^^

Le point intéressant dans leur explication, c'est le "avant/après" :

- interprété -> compilé : perfs x2
- typage dynamique -> typage interprété : perfs x2 à x1000 suivant les cas

Comme quoi c'est pas le fait que ce soit interprété qui influe le plus...

Bin oui, c'est évident qu'on aura toujours de meilleures perfs avec du typage statique…
Mais d'une part, le but de ces langages n'est pas forcément d'avoir les meilleurs perfs du monde, donc on peut tout à fait vanter l'intérêt du typage dynamique et savoir que ça plombe les perfs.

D'autre part, les avantages des langages comme Python par rapport au C ne se limitent absolument pas au typage dynamique (d'ailleurs, perso, je n'en suis pas spécialement fan, et encore moins fan de changer le type d'une variable après sa première affectation).

Après, si on peut avoir des perfs assez proches de celles du C (j'imagine que ça dépend pas mal des conditions, bien évidemment) tout en ayant 10 fois moins de code, ça peut être bien intéressant, et limiter encore plus le code C à quelques portions (surtout avec la possibilité d'interfacer le C et le Python facilement : on peut imaginer toute l'interface en Python et les quelques portions coûteuses en calcul en C).

De mémoire, il y a PyPy qui est une VM compatible Python mais qui peut ajouter le typage statique, avec de bien meilleures perfs (je n'ai jamais essayé non plus).

./4 : bah il me semble qu'on le savait déjà ça, non ? Il n'y a qu'à voir les différences de performances entre certains langages non-natifs à typage fort (C#, Java...) qui peuvent entre autres avoir un JIT efficace, et ceux dynamiques (Python, PHP, Ruby...), par exemple ici (il n'y a que le JavaScript qui puisse presque faire office de contre-exemple, mais les moyens énormes qui ont été déployés ces dernières années pour l'améliorer expliquent peut-être en partie)

J'ai l'impression d'entendre une 10ième fois qu'on a un nouveau langage "presque aussi rapide que le C", sachant qu'à chaque fois le "presque" reste assez conséquent, et que ça ajoute des contraintes telles au langage qu'on peut tout aussi simplement passer au vrai C directement.

Je ne connaissait pas, mais les résultats de performance ne me surprennent pas outre mesure. Le typage dynamique est une plaie pour les performances brutes, c'est plutôt connu.

Je rajouterais a titre personnel que je déteste car je trouve que ça rend le code mois clair dès que l'application devient un peu complexe.
J'ai du mal a comprendre pourquoi il est si populaire ces temps si. Est ce que gérer le typage et quelque chose de si complexe que ça?

flanker (./5) :
on peut tout à fait vanter l'intérêt du typage dynamique et savoir que ça plombe les perfs.

Personnellement je n'ai jamais compris l'intérêt du typage dynamique, à part "c'est plus simple à implémenter", ce qui par conséquent autorise tout le monde (et surtout n'importe qui) à créer des langages boiteux.

C'est aussi beaucoup plus facile d'accès, et "ça en jette" assez facilement...
De fait, tu peux faire super rapidement des trucs qui demanderaient un peu de code si tu utilisais un langage à typage fort, mais en contrepartie, outre les performances inférieures, tu as un piège à con qui se cache sous chaque ligne de code écrite. (Vu que tu ne maîtrises pas à 100% le type de tes variables... Sauf à implémenter un espèce de typage fort par dessus le typage dynamique )
Mais quand on te vante les mérites du typage dynamique, on omet toujours les points négatifs... (Qui sont quand même sacrément négatifs)
Donc le typage dynamique, c'est moderne, c'est facile, c'est beau (ou pas), bref, c'est bien !

(NB: Cela dit avec de la génération de code dans un environnement fortement typé, on peut faire du "typage fort dynamique"... Et ça par contre, ça déchire )

intéressant, un peu comme vala et genie mais avec un langage déjà existant

Ce qui me surprend, c'est qu'on puisse regagner autant en perfs en rajoutant une seule contrainte (certes, elle est de taille) sur un langage déjà conçu.

Après, je suis assez d'accord sur les inconvénients du typage dynamique, perso le système que je trouve le plus propre reste du typage fort avec inférence de type (à la OCaml).

Faudrait faire un Python avec inférence de type, en fait

Tu voudrais pas, genre du Boo ? ^^

Même l'inférence bête de type j'ai du mal a voir l’intérêt. Ce n'est pas couteux en performance mais je trouve qu'on perd en lisibilité, vu que le type n'est plus visible au premier coup d'oeil.

Quel peut donc être l’intérêt de masquer le type d'une variable?

Simplifier l'écriture. Mais je trouve que c'est une très mauvaise raison : un programme n'étant souvent pas écrit autant de fois qu'il n'est lu (sauf projet strictement perso, et encore), c'est la facilité de *lecture* qu'il vaudrait mieux privilégier. Je ne sais pas combien parmi vous ont déjà travaillé à plusieurs sur un gros projet dans un langage dynamique, mais c'est vraiment la misère. Le seul moyen de ne pas se paumer complètement est de s'imposer des conventions hyper strictes (par exemple détailler les entrées et sorties en commentaire de chaque méthode), ce qui revient grosso modo à ce que force naturellement à faire un langage statiquement typé (sauf que comme le compilateur/interpréteur ne peut rien vérifier, c'est sujet aux inévitables erreurs humaines).

Sinon faire une inférence de type dans un langage comme Python, c'est envisageable très localement (genre identifier que ma variable utilisée sur 3 lignes est toujours un entier, super), mais puisqu'il est dynamique et à cause de sa syntaxe minimaliste il y a beaucoup de méthodes qui une fois l'inférence appliquée resteraient génériques, donc le problème ne serait qu'en (petite) partie résolu.

Je trouve au contraire que moins il y a de types, plus le code est lisible (je préfère lire du JavaScript plutôt que du Java, pourtant la syntaxe est similaire), mais c'est peut-être une question d'habitude. Ca rend aussi le refactoring beaucoup plus rapide, pas besoin de modifier toutes les variables quand tu décides finalement que int64_t c'était mieux que int32_t.

Et l'inférence de type ne veut pas forcement dire qu'il n'y a plus de types exprimés. On peut tout a fait spécifier les types dans les interfaces (paramètres des méthodes, etc...) et laisser le compilateur inférer toutes les variables locales en Haxe ou en C++ par exemple.

Quand tu changes un int64_t en int32_t peut-être (et encore, tu vas vraiment faire ça dans tout un projet sans aller vérifier les 3 tonnes d'effets de bords que ça peut provoquer ? sans compter qu'il n'y a à peu près aucune chance pour que ça compile directement après ce genre de transformation), mais dès que tu changes entre des types un peu moins compatibles tu *veux* que ça ne compile plus, pour être certain de repasser sur tous les endroits du code où ça fait apparaître des problèmes. Prends un projet conséquent en JavaScript, et supprime un champ dans un objet. Par quel miracle veux-tu avoir une chance de trouver tous les endroits qui l'utilisaient, sachant qu'il peut y avoir des accès complètement dynamiques (object[fieldName]). Si tu ne t'es pas imposé de spécifier en commentaire les champs utilisés par chaque méthode qui faisait référence à ce champ, tu es cuit (ou bien tu peux aussi lancer le programme N fois et espérer être tombé sur tous les bugs quand tu auras réussi à le faire fonctionner à nouveau ).

Si tu spécifies des types dans les interfaces, bien sûr que ça résout l'ambiguïté, mais ça n'est plus vraiment ce que j'appelle un langage dynamique pour le coup.

Ma réponse n'était pas claire mais je parlais de l'intérêt de l'inférence de type dans un langage typé statiquement (c'était une réponse au post de Uther). Je suis tout a fait d'accord avec toi concernant le refactoring dans un langage dynamique, c'est catastrophique.

Zeph (./14) :
Simplifier l'écriture. Mais je trouve que c'est une très mauvaise raison : un programme n'étant souvent pas écrit autant de fois qu'il n'est lu (sauf projet strictement perso, et encore), c'est la facilité de *lecture* qu'il vaudrait mieux privilégier. Je ne sais pas combien parmi vous ont déjà travaillé à plusieurs sur un gros projet dans un langage dynamique, mais c'est vraiment la misère. Le seul moyen de ne pas se paumer complètement est de s'imposer des conventions hyper strictes (par exemple détailler les entrées et sorties en commentaire de chaque méthode), ce qui revient grosso modo à ce que force naturellement à faire un langage statiquement typé (sauf que comme le compilateur/interpréteur ne peut rien vérifier, c'est sujet aux inévitables erreurs humaines).

Je suis entièrement d'accord sur le fait que la relecture et surtout la navigation facile dans de code est 100 fois plus important que la facilité d'écriture.

Et je trouve d'ailleurs que la facilité d'écriture de l'inférence de type est quand même très faible. Un "var i;" ne ne parait pas plus simple à écrire qu'un "int i;"

nitro (./15) :
Je trouve au contraire que moins il y a de types, plus le code est lisible (je préfère lire du JavaScript plutôt que du Java, pourtant la syntaxe est similaire), mais c'est peut-être une question d'habitude. Ca rend aussi le refactoring beaucoup plus rapide, pas besoin de modifier toutes les variables quand tu décides finalement que int64_t c'était mieux que int32_t.

C'est sans doute en effet une question d'habitude car pour moi, c'est tout l'inverse.
Quant au refactoring, c'est vrai que c'est un avantage auquel je n'avait pas pensé, mais au final, l'utilité me parait limitée, et je préfère vérifier manuellement qu'il n'y a pas d'effet de bord dans ces cas là.

Uther (./18) :
Et je trouve d'ailleurs que la facilité d'écriture de l'inférence de type est quand même très faible. Un "var i;" ne ne parait pas plus simple à écrire qu'un "int i;"

Ouais enfin,
SimplePasswordHasher *simplePasswordHasher = new SimplePasswordHasher();
On peut imaginer simplifier la syntaxe, mais bon. Perso j'aime bien quand même quand on sait de quoi on parle.

Dans ce cas la d'accord, mais plutôt que faire de l'inférence du coté de la déclaration on pourrait faire du coté du new :
SimplePasswordHasher *simplePasswordHasher = new();

Aussi ouais. Tu connais un langage qui fait ça ?

Je considère que l'inférence de types sur les types primitifs n'est pas forcement une bonne idée (on devine pas forcément avec le nom de la variable que c'est un entier 32 bits ou 64 bits) par contre, il n'y a aucune raison de s'en priver pour les types définis par l'utilisateur.
En général, la sémantique est plus intéressante que le type exact de la valeur, même s'il n'est pas totalement inutile de connaître celui-ci.
De plus, comme dans l'exemple donné par Brunni, le type apparaîtrait encore clairement avec inférence de type.
Et l'inference de type "à droite" est une très mauvaise idée... Simplement parce qu'il y a plus dans l'inference de type qu'une simple utilisation de new...

Exemple concret en C#: var mainMethod = typeof(Program).GetMethod("Main"); foreach (var parameter in mainMethod.GetParameters) Console.WriteLine(parameter.Name);

Quand je fais ça, je me fiche royalement que le type exact de "mainMethod" soit MethodInfo, ça représente une méthode et une méthode a des paramètres, c'est tout ce qui m'intéresse.
De même, je me fiche que "parameter" soit de type "ParameterInfo". Un paramètre de méthode à un nom un type, et quelques autres propriétés (position, valeur par défaut, etc.) mais si tu ne sais pas ça, ce n'est pas le fait de connaître le type exact qui va t'aider beaucoup plus.

Et fort heureusement, l'inference de type est déterministe dans les langages fortement typés, donc si tu as un doute, tu trouveras rapidement le type de ta valeur en utilisant un IDE moderne

Ben là justement, je ne te suis pas entièrement Golden. En voyant ton code ce n'est pas clair d'où vient GetParameters. Ce n'est pas non plus clair qu'est-ce que c'est ton paramètre, et le fait qu'il a un nom (et si on veut savoir ce qu'il a d'autre ?).
Enfin là je trouve que ton code a plus ou moins la lisibilité d'un langage dynamique (excepté qu'il est cette fois possible de retrouver le type en passant la souris sur l'appel à la méthode, je suppose, donc beaucoup mieux en pratique quand même).

Brunni (./21) :
Aussi ouais. Tu connais un langage qui fait ça ?

Malheureusement non, mais j'aimerais bien.

GoldenCrystal (./22) :
Quand je fais ça, je me fiche royalement que le type exact de "mainMethod" soit MethodInfo, ça représente une méthode et une méthode a des paramètres, c'est tout ce qui m'intéresse.

Tu t'en fiche parce que c'est du code assez simple que tu as écris et qui fait appel a une API que tu connais.
Mais quand tu dois repasser sur du code plus compliqué que tu n'as pas fais toi même, je trouve que ça peut vite devenir lourd.

Brunni (./23) :
Ben là justement, je ne te suis pas entièrement Golden. En voyant ton code ce n'est pas clair d'où vient GetParameters.

Et qu'est-ce qui te laisse penser qu'en connaissant le nom du type, tu connaîtrais automatiquement tous ses membres ? À ma connaissance, ce n'est pas le cas... Si tu ne connais pas, tu es de toutes façons bon pour aller lire la documentation. (Ou faire un coup de F12 sous Visual)

Ce n'est pas non plus clair qu'est-ce que c'est ton paramètre

Si en lisant ce code comme une phrase (recuperer la methode Main de Program, et pour cacun de ses parametres, afficher le nom) tu ne comprends pas ce que fait le code, bah c'est peut être un problème de ton côté... Pour moi c'est du code auto-documenté... (Du fait qu'en le traduisant directement en langage humain, tu obtiens sa fonction)

et le fait qu'il a un nom

Ben t'as pas besoin de le "savoir" vu que c'est écrit dans le code, et que si le code était faux il compilerait pas

et si on veut savoir ce qu'il a d'autre ?

Quan tu lis du code, tu t'interroges souvent sur ce que le code aurait pu faire (fonctionnellement) mais qu'il ne fait pas ?
Et encore une fois, si tu ne connais pas le type, je ne vois pas en quoi connaître son nom t'en dira plus sans aller lire la documentation.

Enfin là je trouve que ton code a plus ou moins la lisibilité d'un langage dynamique.

Sur ce point la c'est vrai que si tu extrais du code au milieu d'une fonction, il est possible qu'il ne soit pas plus lisible que l'équivalent en JavaScript. Mais si la sémantique (Nom des variables, possibilité de comprendre le "sens" du code) est bonne, tu en tireras quand même quelque chose...
Par contre, tout est différent des que tu prends en compte le contexte. Le langage utilisé, les frameworks utilisés, tous ont leur règles. Si tu ne les connais pas, c'est une lacune, parce que tu ne connais pas le contexte (et d'une certaine façon, c'est de ta faute).
Et avec le contexte, dans un langage fortement typé, tu déduis beaucoup plus de choses que dans un langage dynamique. Juste parce que tu sais que le type d'une variable/d'un champ/d'un paramètre de fonction est fixé. Donc les possibilités d'interprétation et donc d'erreur (mauvais type au mauvais endroit) sont énormément réduites.

excepté qu'il est cette fois possible de retrouver le type en passant la souris sur l'appel à la méthode

Tout à fait, l'IDE fait beaucoup pour toi. Mais même sans ça (inférence de types) je trouve que ça serait suicidaire de coder sans une bonne IDE. C'est pas parce tu connais les frameworks, ou même les noms des types de toutes les variables que tu connais tous les membres par cœur. Tu sais que tel truc à telle fonction, que tel autre truc s'utilise comme ça, et ensuite tu laisses l'IDE et la documentation te guider...

(Je pense que ça répond aussi à Uther du même coup)

Uther (./13) :
Même l'inférence bête de type j'ai du mal a voir l’intérêt. Ce n'est pas couteux en performance mais je trouve qu'on perd en lisibilité, vu que le type n'est plus visible au premier coup d'oeil.

Quel peut donc être l’intérêt de masquer le type d'une variable?

Pour cela, faut une IDE un peu plus complexe, qui soit capable de calculer la signature de ta fonction, de l'afficher, et surtout de garder en mémoire la signature des autres fonctions pour l'auto-complétion.

GoldenCrystal (./12) :
Tu voudrais pas, genre du Boo ? ^^

Ça l'air pas mal, en effet Mais également un peu mort

Il y a finalement assez peu de langages avec inférence de type, c'est bien dommage. Faudrait que j'essaye Scala ou F# un jour…

flanker (./26) :
Il y a finalement assez peu de langages avec inférence de type, c'est bien dommage. Faudrait que j'essaye Scala ou F# un jour…

J'ai pourtant au contraire l'impression que tous les langages font ça maintenant. Que ce soit tous le s nouveaux langages comme Go ou Rust, ou les anciens qui s'y mettent comme le C et C++

Zeph (./3) :
Mais du coup à moins de préférer la syntaxe du Python, on avait pas franchement besoin de faire un 360° pour en revenir à ce point-là ^^

Le principal intérêt de Cython est qu'il permet de coder facilement des extensions Python en natif, ce qui est une manière de coder des bindings Python pour des bibliothèques en C.

On peut aussi s'en servir pour remplacer carrément Python, mais ce n'est pas son utilisation la plus courante.

Uther (./13) :
Quel peut donc être l’intérêt de masquer le type d'une variable?

Ça a un intérêt pour le polymorphisme, mais l’intérêt principal de l’inférence de types n’est précisément pas de masquer les types, au contraire, c’est de les afficher. Tu écris un truc et la machine infère le type et te le donne. C’est comme ça que fonctionne ocaml par exemple.
Évidemment le but n’est pas que le lecteur humain doive deviner tout seul les types des fonctions, ça n’aurait aucun intérêt (et si c’est pour les écrire en commentaire... )

Uther (./20) :
Dans ce cas la d'accord, mais plutôt que faire de l'inférence du coté de la déclaration on pourrait faire du coté du new :
SimplePasswordHasher *simplePasswordHasher = new();

Euuuuuuh, une expression dont la sémantique dépend du contexte dans lequel elle apparaît, ça te paraît pas un peu casse-gueule ?
Tu veux pouvoir écrire un truc du genre : fonction_qui_prend_un_paramètre_de_type_t(new())
et que new() soit automatiquement transformé en new t() dans ce cas aussi, ou pas ?
si oui, il me semble que c’est bien une forme d’inférence à l’envers, mais bonjour la lisibilité du code
si non, en fait ce que tu appelles inférence c’est juste une abréviation ad hoc spécifique au cas particulier de l’initialisation d’une variable, c’est plutôt ça je suppose ?
"t var = new(x, y, z);" abrège "t var = new t(x, y, z);" mais dans toute autre circonstance new() est interdit ?

je suis pas trop fan

La dernière version du standard C++ gère l'inférence de types.
Et si vraiment tu as besoin d'une variable à type dynamique, cf. QVariant.
Bref, comme d'habitude, il y a déjà tout en C++.