Differences

This shows you the differences between two versions of the page.

--- devel:python [2015/06/02 16:32] – [Python vs l'interpreteur Oofelie (OE)] ziane
+++ devel:python [2024/03/01 16:40] (current) – [Qu'est ce que c'est?] boman
@@ Line 1: / Line 1: @@
 ====== Interface python ======
@@ Line 16: / Line 15: @@
     * [[http://www.python.org/|python.org]] : le site officiel
     * [[http://diveintopython.org/|dive into python]] : un bon tutorial
-    * [[http://www.cetus-links.org/oo_python.html|cetus]] : un bon paquet de liens
-    * [[http://starship.python.net/crew/hinsen/|Python and Science]] : un tutorial "scientifique"
-    * [[http://www.effbot.org/zone/librarybook-index.htm|the standard library]] : une description de la lib standard en pdf
 ===== Python vs l'interpreteur Oofelie (OE) =====
@@ Line 79: / Line 75: @@
-===== L'interface python de metafor =====
+===== L'interface Python de Metafor =====
-Python possède une API écrite en C qui permet d'écrire des "modules" (comme les packages en java, ou namespaces en C++). Metafor est donc un module de Python.... enfin, presque. En effet, n'oublions pas que grâce au magnifique travail d'igor sur les matériaux et les éléments, il n'est pas possible d'initialiser correctement ceux-ci quand ils sont regroupés dans une lib. J'ai du donc choisir d'intégrer python dans l'exécutable metafor.
+Python possède une API écrite en C qui permet d'écrire des "modules" (comme les packages en java, ou namespaces en C++). Metafor est donc un module de Python.... enfin, presque. En effet, n'oublions pas que grâce au magnifique travail d'Igor sur les matériaux et les éléments, il n'est pas possible d'initialiser correctement ceux-ci quand ils sont regroupés dans une lib. J'ai dû donc choisir d'intégrer Python dans l'exécutable Metafor.
-Cette interface n'est pas simple à écrire parce que l'API Python est complexe. J'etais donc un peu découragé jusqu'au jour où j'ai vu le logiciel [[http://www.swig.org/|Swig]] (Simplified Wrapper and Interface Generator) qui se charge du boulot. Mieux encore, Swig crée des "shadow classes" qui permettent d'obtenir des objets Python malgré l'API écrite en C. Swig gère aussi tous les problèmes de cast (ce qui pose beaucoup de problèmes dans l'interpréteur Oofelie).
+Cette interface n'est pas simple à écrire parce que l'API Python est complexe. J'étais donc un peu découragé jusqu'au jour où j'ai vu le logiciel [[http://www.swig.org/|Swig]] (Simplified Wrapper and Interface Generator) qui se charge du boulot. Mieux encore, Swig crée des "shadow classes" qui permettent d'obtenir des objets Python malgré l'API écrite en C. Swig gère aussi tous les problèmes de cast (ce qui pose beaucoup de problèmes dans l'interpréteur Oofelie).
-Swig n'est pas qu'un simple traducteur: il gère également la surcharge des fonctions membres (absentes dans python puisque les types d'objets ne sont pas explicites) et l'héritage multiple. Tout ceci via un système de cast dynamique assez bien fait et relativement bien optimisé (j ai jeté un oeil, c'est largement mieux fait que OE). Enfin, Swig gère correctement les variables globales (qui, elles, ne sont pas des références python)
+Swig n'est pas qu'un simple traducteur: il gère également la surcharge des fonctions membres (absentes dans Python puisque les types d'objets ne sont pas explicites) et l'héritage multiple. Tout ceci via un système de cast dynamique assez bien fait et relativement bien optimisé (j ai jeté un œil, c'est largement mieux fait que OE). Enfin, Swig gère correctement les variables globales (qui, elles, ne sont pas des références Python).
-L'interface Python de metafor se réduit donc à des fichiers input de Swig (fichiers ''.i'' et ''.swg''). Les fichiers ''.i'' donnent des ''.cpp'' via swig qui sont compilés un à un pour former des modules. Les fichiers ''.swg'' sont des fichiers inclus par les ''.i'' qui ne correspondent pas à un module. A l'heure actuelle, ces fichiers interfacent toutes les fonctions membres (publiques) des classes Metafor et Oofelie utilisées dans le célèbre cas-test "''cont2''".
+L'interface Python de Metafor se réduit donc à des fichiers input de Swig (fichiers ''.i'' et ''.swg''). Les fichiers ''.i'' donnent des ''.cpp'' via Swig qui sont compilés un à un pour former des modules. Les fichiers ''.swg'' sont des fichiers inclus par les ''.i'' qui ne correspondent pas à un module. A l'heure actuelle, ces fichiers interfacent toutes les fonctions membres (publiques) des classes Metafor et Oofelie utilisées dans le célèbre cas-test "''cont2''".
-Lorsqu'on lance ''metafor'', on se retrouve en ligne de commande Python. Le module metafor est deja chargé en mémoire ainsi que le module utilitaire (''toolbox.utilities''). Il est donc possible de lancer un cas-test (''myTest.py'') par la simple commande:
+Lorsqu'on lance ''Metafor'', on se retrouve en ligne de commande Python. Le module Metafor est déjà chargé en mémoire ainsi que le module utilitaire (''toolbox.utilities''). Il est donc possible de lancer un cas-test (''myTest.py'') par la simple commande:
     meta('myTest')
@@ Line 104: / Line 100: @@
-Avoir une première interface est très simple. Le premier problème était les cast implicites cachés derrière les ''get_properties()''. Heureusement, Swig peut gérer ça facilement (un peu comme le ''I_::new_child_from_id()'' de OE). J'ai du aussi gérer les ''std::string'' et les ''UserNo'' via des "''typemaps''" de Swig (un système qui permet de faire des casts implicites automatiques).
+Avoir une première interface est très simple. Le premier problème était les cast implicites cachés derrière les ''get_properties()''. Heureusement, Swig peut gérer ça facilement (un peu comme le ''I_::new_child_from_id()'' de OE). J'ai dû aussi gérer les ''std::string'' et les ''UserNo'' via des "''typemaps''" de Swig (un système qui permet de faire des casts implicites automatiques).
 Après ceci, le premier résultat ne ressemblait pas trop à l'interpréteur Oofelie. Par exemple, les ''Lock''s étaient stockées dans une variable ''cvar''. Il fallait donc écrire:
@@ Line 110: / Line 106: @@
     loadingset.define(1,NODE_PO, Key(cvar.TX|cvar.GD|cvar.RE), 0, f)
-ce qui est lourd. J'ai donc réussi à "descendre" les variables cvar dans chaque namespace (et ceci de manière automatique - sans écrire). Bref, si on ajoute une ''Lock'', ca marche tout seul).
+ce qui est lourd. J'ai donc réussi à "descendre" les variables cvar dans chaque namespace (et ceci de manière automatique - sans écrire). Bref, si on ajoute une ''Lock'', ça marche tout seul).
 Même remarque pour les noms d'éléments, de matériaux, de ''Elementproperties'', de ''MaterialProperties'', identificateurs, etc.
@@ Line 121: / Line 117: @@
     * Autre moyen: regarder ce que j'ai fait dans ''apps/qs/cont2.py''
     * La syntaxe est extrêmement proche de celle d'Oofelie (ouf). Le passage des ''.e'' aux ''.py'' est presque immédiat.
-    * Je vous conseille aussi de jeter un oeil à Swig.
+    * Je vous conseille aussi de jeter un œil à Swig.
     * Vous pouvez également regarder l'interface Z-Mesh.
@@ Line 128: / Line 124: @@
     * charger un fichier : ''execfile('fichier.py')'' ou ''import fichier''
     * ''dir(module)'' : "''status''" de matlab
-    * ''dir(variable)'' : donne les fcts membres
+    * ''dir(variable)'' : donne les fonctions membres
     * ''PYTHONPATH'' : équivaut au ''LIBOOFE''
     * ''type(variable)'' : donne le type de variable
     * ''print 'variable=', variable'' : imprime ''variable = valeur''
-    * tout est objet (même une fonction)
+    * tout est objet (même une fonction).
 Différences par rapport à l'interpréteur OE: