Je viens de finir de rédiger (relire, corriger, etc.) cet article et de l'envoyer en validation de mon côté.
Cool article, je viens de le lire. Chapeau !
Bonjour,
J'essaie de me mettre à python pour me changer un peu du Java, du C++, du PHP, du JavaScript et du lua. Vos idées et vos débuts de tutoriels me paraissent globalement très bons et j'ai hâte de pouvoir découvrir des suites à ce que vous avez déjà écrit.
Je ne sais pas si je serais en mesure de vous aider, et si oui comment. En ce moment je programme un petit logiciel en C++ qui embarque python 3. Tout est sur github mais vu que c'est pour moi tout seul, je ne commente pratiquement rien et je suis à des années lumières des bonnes pratiques.
A l'époque du SDZ, j'avais commencé un tutoriel lua en partant des bases mais j'ai vite arrêté par manque de temps et de motivation; à priori je ne me sens pas avoir la patience d'écrire seul un tutoriel complet partant du b.a. ba.
En attendant, je vous encourage à continuer parce que ça m'intéresse.
Voilà…
QuentinC me fait penser qu'il faudrait un article sur les bonnes pratiques en Python avec la découverte de la PEP8 !
@QuentinC : écrire un gros contenu est difficile, c'est pour ca qu'on veut séparer en petit morceaux. Par contre si tu veux écrire un mini tuto sur comment intégrer python dans une application C++, n'hésite pas, ça a tout a fait sa place.
Par contre si tu veux écrire un mini tuto sur comment intégrer python dans une application C++, n'hésite pas, ça a tout a fait sa place.
La doc n'est de base pas si mal foutue (Extending and embedding). J'avoue que j'ai du mal à voir en quoi je pourrais faire mieux.
LE seul truc un peu con c'est qu'ils recommandent de ne pas le faire à la mano alors que c'est ce qu'ils expliquent par la suite. Du coup je n'ai pas fait ce qui était recommandé, je l'ai fait à la mano quand même, avec mon propre bidule à base de template C++11; je me suis bien amusé mais j'ai l'impression d'être un gros taré pour avoir pondu un truc pareil.
Pour info, maintenant qu'ils sont en feature freeze et qu'on sait ce que va contenir la 3.5, je compte faire un article pour présenter les principales nouveautés. J'ai juste commencé un pré-brouillon. Si ça dit à certains de me donner un coup de main, n'hésitez pas à me faire signe et je vous ajouterais dès que j'aurai un truc avec un plan un minimum stable. Le deadline étant le 13 septembre, pour la sortie finale.
Je veux bien participer.
Bon, accessoirement, faut que j'écrive mon deuxième article sur les coroutines (qui explique le principe des IO asynchrones) avant que celui-ci ne sorte, parce que ce sera plus simple d'expliquer les nouveaux éléments syntaxiques de Python 3.5 (async, await) en se reposant dessus. 
Par contre si tu veux écrire un mini tuto sur comment intégrer python dans une application C++, n'hésite pas, ça a tout a fait sa place.
La doc n'est de base pas si mal foutue (Extending and embedding). J'avoue que j'ai du mal à voir en quoi je pourrais faire mieux.
Il y a plein d'autres manières de faire (SWIG, Boost.Python, PythonQt) qui ont tous leurs avantages et leurs inconvénients. C'est le genre de truc qui m'intéresse, donc j'écrirai peut-être quelque chose là dessus, mais pas tout de suite.
Je ne pense pas que ç'ait encore un intérêt d'utiliser (donc d'écrire sur) SWIG aujourd'hui.
C'est une techno vieillissante dont le métier est réalisé de façon plus performante et plus pythonique par Cython.
SWIG garde deux avantages sur Cython pour le C++ :
mymod.i et %include header.hpp et c'est bon. Avec Cython ou Boost.Python il faut expliciter ce que l'on souhaite exporter. Pour des tests quick and dirty ou une base de code qui change beaucoup c'est un avantage.Pour moi, Cython se compare surtout avec Boost.Python. Dans Boost on écrira du code C++ et avec Cython du code 'Python'. Mais dans les deux cas il faut écrire explicitement ce que l'on souhaite exporter, et on ne gagne que Python. C'est le prix pour avoir des interfaces propres et plus pythonesques, sur lesquelles on a un contrôle total.
… et un binding 7 à 10 fois plus léger en performances, oui.
… et un binding 7 à 10 fois plus léger en performances, oui.
Je n'ai pas parlé de perfs =) Mais dans mon domaine (prog scientifique), être capable de faire rapidement un binding, même quick and dirty, même non optimal, reste utile. Tout ça pour dire que SWIG n'est pas à jeter à la poubelle.
Sur les deux lib C++ que j'ai liés à Python, une l'a été avec SWIG, et l'autre avec Boost.Python. Celle lié avec Boost.Python a une interface stable qui ne devrait pas trop changer, et celle liée avec SWIG change constamment. L'intérêt du binding Python ici est de pouvoir effectuer des tests et changer les paramètres de la simulation sans avoir à recompiler un main à chaque fois.
Je n'ai pas parlé de perfs =) Mais dans mon domaine (prog scientifique), être capable de faire rapidement un binding, même quick and dirty, même non optimal, reste utile.
C'est dommage, tu ne dis pas en quoi, personnellement, à part le fait qu'il est multi langages, je ne vois pas trop.
Je n'ai jamais comparé SWIG et cython en terme de performance, mais en restant cohérent avec ma 1ère remarque, je dirais que cython, est fait exclusivement pour Python avec C/C++, ce qui le rend normalement spécialisé pour le langage Python.
cython est pour moi un autre langage, ce qui ne sera pas de l'avis de tout le monde, mais en ce qui me concerne pour l'apprendre, c'est comme cela que je l'ai pris.
Dans Boost on écrira du code C++ et avec Cython du code 'Python'.
Oui mais on ne fait pas du C 
Du coup je ne sais pas si la comparaison doit se faire…
cython est pour moi un autre langage, ce qui ne sera pas de l'avis de tout le monde, mais en ce qui me concerne pour l'apprendre, c'est comme cela que je l'ai pris.
C'est également la façon dont je le vois. Un Python auquel on aurait injecté le typage de C++ et les pointeurs du C. Je pense également que pour l'utiliser correctement (en tirer partie le plus possible et comprendre comment il marche), c'est précisément de cette manière qu'il faut l'aborder.
Je ne sais pas. Pour bien appréhender cython il faut tout de même bien connaître la mécanique interne de cpython. Et d'ailleurs il n'a de sens que dans cet écosystème. Je vois pas trop l'intérêt de faire du cython pour faire du cython, decorélé du Python. Pour moi c'est plus une extension du Python ce qui présuppose de le connaître.
Évidemment pour connaître cython, il faut avoir les connaissances en python et en C (voir C++), on ne dit pas le contraire, et c'est logique ! Mais la syntaxe diffère, c'est un mixte entre du langage C et du python, j'ai donc une autre façon de parler, d'où mon expression autre langage.
C'est dommage, tu ne dis pas en quoi, personnellement, à part le fait qu'il est multi langages, je ne vois pas trop.
Je ne comprends pas ce que tu veux dire =(. Je ne suis pas un fan de SWIG, loin de là. Mais il reste encore utile pour des gens qui ne veulent/peuvent pas investir (en temps, en apprentissage, …) dans l'écriture d'un binding. Le seul avantage de SWIG, c'est qu'il est capable de générer tout seul la glue nécessaire entre C++ et Python. De là découle tout le reste : il est (peut-être) moins performant ; il est super simple à utiliser ; …
De là découle tout le reste : il est
(peut-être)moins performant
Fix'd. J'ai fait moi-même le test pour le boulot et le résultat est sans appel.
Mais il reste encore utile pour des gens qui ne veulent/peuvent pas investir (en temps, en apprentissage, …) dans l'écriture d'un binding
Oui et non car tu dis ceci, qui m'interroge
De là découle tout le reste : il est (peut-être) moins performant
C'est tout de même une des principales raison d'interfacer ces deux langages, on sait très bien que python seul n'est pas suffisamment optimisé. Toi qui fait du scientifique, as-tu essayé le mixte numpy + cython ? Si l'objectif est la performance (je parle en terme de vitesse d'exécution d'un code python), alors on sait qu'il faudra mettre la main dans le cambouis. Mais cython à y réfléchir, n'est pas si complexe que cela, et la documentation est ultra bien faîte, alors il ne devrait pas y avoir trop de soucis sur le temps d'investissement.
Fix'd. J'ai fait moi-même le test pour le boulot et le résultat est sans appel.
Mieux valait faire le test pour confirmer les dires (merci nohar), mais c'est vrai que le doute était très restreint… Beaucoup de sites/forums comparent ces deux types d'interfaçage avec toujours un net avantage à cython.
Juste pour dire que je n'ai pas abandonné mon projet de tuto sur les cbv avec django, j'ai même créé le projet git qui va avec ici par contre je n'ai pas encore eu le temps de prévoir le plan complet.
@fred : Je pense qui interesse Luthaf dans swig c'est de pouvoir se servir de Python comme glue. Ça permet de facilement automatiser des batteries de tests et traiter les résultats. Si j'ai bien compris il ne dit pas que Cython est moins bien, bien au contraire, mais que Swig est plus rapide à utiliser pour faire un binding tôt dans le process. Cython est tres bien quand ton binding Python est le produit principal mais il a un cout non négligeable quand ton produit est la lib et où le binding python n'est qu'une feature parmit d'autres.
Le couple Cython + Numpy est, pour l'avoir testé au boulot, très efficace mais ce n'est pas forcément dans le même schema. C'est quand tu as un code utilisant numpy que tu veux encore optimiser. Mais tu fais ça qu'à la fin, quand le code est stabilisé, car ça prend du temps et c'est moins maintenable que du code python pur.
Kje a tout dit ! Le produit de base est une lib C++, qui a un binding Python. Pas un code Python que je veux accélérer.
Et en effet, quitte à re-écrire des bouts de code Python en C++, autant le faire avec Cython et avoir toute la performance facilement.
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte