Python Connaissez-vous Cython ? - Page 2

-déjà+enfin

Sally (./29) :
Ça a un intérêt pour le polymorphisme

J'aimerai bien avoir un exemple parceque j'ai du mal a voir en quoi ca aide au polymorphisme.

Sally (./29) :
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.

Pour moi a partir du moment ou tu laisse la machine te donner ton type, c'est que tu ne maitrise plus ce que tu fais.

GoldenCrystal (./31) :
-déjà+enfin

-enfin+malheureusement

Uther (./32) :
J'aimerai bien avoir un exemple parceque j'ai du mal a voir en quoi ca aide au polymorphisme.

Mouais que ça "aide" c’est un bien grand mot, je voulais juste dire que tu peux vouloir ne pas préciser le type d’une variable pour le laisser ouvert (n’importe quel type donc), mais évidemment rien n’empêche d’utiliser explicitement des variables de type. Ce qui a un intérêt c’est de pouvoir dire d’une façon ou d’une autre « on ne sait pas quel est le type de la variable » (comme ça on est sûr que la fonction est polymorphe). Bon en java tu peux lui donner le type Object par exemple mais c’est un type qui n’est pas significatif (et c’est quand même plus ou moins une manière de masquer le "vrai" type de la variable).

Uther (./32) :
Pour moi a partir du moment ou tu laisse la machine te donner ton type, c'est que tu ne maitrise plus ce que tu fais.

Ben je ne vois pas trop le problème (la machine ne décide pas à ta place du type, elle *calcule* le type principal de l’expression, de toute façon il n’y a pas le choix, sauf si tu veux volontairement perdre de l’information auquel cas tu as toujours la possibilité de donner explicitement un type moins précis ou moins polymorphe).

Normalement tu attends un certain type pour ce que tu écris, si l’ordinateur t’en donne un autre c’est généralement que tu as fait une erreur, mais tu peux faire une erreur même en ayant déclaré le type (elle ne se manifestera juste pas exactement de la même façon), je ne vois pas en quoi tu maîtrises moins.

Sinon il faut voir aussi que l’inférence est surtout intéressante dans un langage où on a une algèbre de types un tant soit peu complexe (où on peut donc avoir des types qui prennent plusieurs lignes le cas échéant, par opposition à un langage comme java où la complexité va rarement au-delà d’un generic avec un ou deux paramètres), en particulier avec des fonctions polymorphes ou d’ordre supérieur. Ce n’est pas par hasard que ça existe depuis la nuit des temps dans les langages fonctionnels.
Évidemment si toutes tes variables sont des int ça ne t’est pas forcément utile

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

Java 7 le fait un peu pour les génériques, ça ressemble à ce que Sally décrit. (=simple abréviation)

List<String> plop = new LinkedList<>();

Il semble qu'on puisse également virer le <>

En effet on peut virer le <> mais le compilateur va te mettre un warning car ça signifie que tu ignores la généricité de la classe, ce que tu n'est plus censé faire depuis Java 5.

ah oui.

!up
Une petite présentation d'un développeur de Cython (compilation de Python en C) et PyPy (machine virtuelle Python).
https://speakerdeck.com/alex/why-python-ruby-and-javascript-are-slow


En gros, il explique que les mauvaises perfs ne sont pas dues au typage dynamique, mais bien aux allocations mémoire bien plus nombreuses, avec les recopies qui vont avec.

Je n'ai pas regardé mais si c'est ça c'est pas vraiment une révélation, depuis que tous ces langages font du JIT ce sont les allocations non maîtrisées et le garbage collector qui coûtent cher. C'est exactement le même problème que quand on fait du C++ avec un peu trop de STL, et qu'on se rend compte que son programme alloue 10 fois plus et tourne 10 fois moins vite que si on avait fait à peu près la même chose en C.

Zeph (./39) :
ce sont les allocations non maîtrisées et le garbage collector qui coûtent cher.

C'est bien pour ça que le Java raaaaaaaaaaaame à foooooooooooond.

./40 > Oui, je suis d'accord avec toi. Ce que j'ai trouvé intéressant comme info, c'est que le typage dynamique ne coûte finalement pas si cher que ça. Je pensais que l'effet était plus important.

Donc faire des primitives avec un accès plus fin à la mémoire (du genre une méthode my_string.lower() en place, préallocation des listes, etc.) pourrait améliorer les choses tout en conservant pas mal de souplesse.

flanker (./41) :
Ce que j'ai trouvé intéressant comme info, c'est que le typage dynamique ne coûte finalement pas si cher que ça. Je pensais que l'effet était plus important.

Bah, ça "ne coûte pas si cher que ça" si on a un JIT qui fait plein d'heuristiques pour deviner le type, ce qui 1. prend du temps et 2. n'est pas toujours possible (ou seulement quand on est déjà presqu'en train d'exécuter le code, du coup voir 1.). Le plus bizarre, c'est que le présenteur présente ça comme un problème résolu tout en se plaignant plus tard des heuristiques nécessaires pour combler une API défaillante. Je considère les inférences de type comme un parfait exemple d'une telle heuristique. Le typage dynamique est pourri, ça empêche aussi de diagnostiquer pas mal d'erreurs de programmation au temps de la compilation.

./41 : Le problème c'est que l'un des but des langages haut niveau c'est de s'abstraire le plus possible des contraintes de gestion de la mémoire, parce que c'est chiant. Ajouter des primitives qui donnent à nouveau ce contrôle ça devient à briser l'abstraction, et ça ouvre la porte à du code plus complexe avec un risque de bugs plus important.

À mon avis, cette lenteur est le prix à payer quand on utilise un langage plus confortable, et avec les technologies d'aujourd'hui ce prix n'est même plus tellement important. Comme le dit l'auteur de la présentation il restera toujours des optimisations inaccessibles à cause de la conception même du langage, mais il y a aussi un tas d'erreurs simples à éviter pour ne pas empêcher le compilo et/ou la VM de faire leurs boulot le mieux possible, et quand un programme Python / Java / C# ou autre est lent il y a probablement plein de choses à améliorer avant de se plaindre du langage en lui-même.

Par contre je suis tout à fait de l'avis de Kevin concernant la détection des erreurs de compilation qui fonctionne très mal avec l'abstence de typage, alors que le service le plus important que peut rendre un compilateur c'est de valider le code autant que possible. Je ne sais pas trop ce qu'on peut améliorer de ce point de vue, mais c'est clairement une énorme lacune des langages dynamiques à l'heure actuelle.

./43 > je suis d'accord pour dire que le typage est important pour une validation a priori du code, sans compter tout ce que cela permet (refactoring, etc.). Simplement, avoir un typage dynamique est quand même bien pratique parfois

Ceci dit, on peut tout à fait imaginer un typage qui serait simplement optionnel. C'est d'ailleurs le cas en Objective-C, qui permet de faire du typage statique ou du typage dynamique, au choix.
De la même façon, les méthodes que j'évoquerais devraient être optionnelles, l'idée étant de permettre d'optimiser uniquement les quelques morceaux de code qui peuvent être critiques.

D'ailleurs, c'est un truc que j'aime bien avec Python : on a différents niveaux d'optimisations :
- fichiers codés en pur Python,
- utilisation de Pypy (VM Python avec du JIT) avec du Python pur,
- libs spécialisées (genre numpy : types de données optimisés avec pas mal de fonctions sur les matrices),
- ctypes dans un code Python pour utiliser des structures C ou des fonctions C (dans un .dll ou un .so),
- cython : code Python pur avec des annotations (dont le typage) optionnelles, transformé en C puis compilé de façon transparente à la première exécution (ou sur demande),
- utilisation d'extensions Python codées en C / CUDA / OpenCL / MPI.

Du coup, on peut utiliser un langage souple mais lent pour les parties qui n'ont pas besoin d'être optimisées et qui sont faciles à relire (genre la lecture des arguments, etc.), puis un langage plus contraint pour les parties plus sensibles, tout en conservant un ensemble assez cohérent.