Méta-MCI (MVP) a écrit :
> Bonjour !
>
> Il y a une conversation asynchrone, sur gname.org (relais NNTP de listes
> de diffusion) sur un sujet qui m'intéresse, mais en anglais, ce qui fait
> que je n'arrive pas à suivre.
>
> En gros : il y a un pythonien qui a utilisé les DLL de Python.NET avec
> IronPython, de façon à permettre à ce dernier un bien meilleur accès à
> PythonC.
>
> Mais, ça, c'est ce que j'ai cru comprendre. Suis-je en phase ? Et, où
> cela en est-il ? Au balbutiements ? à la faisabilité ? Est-ce utilisable
> ? Est-ce dispo ? Où ?
>
> Merci d'avance à toute personne qui fournira des explications plus
> justes, plus complètes, et en français...

J'ai trouvé cette conversation:
http://thread.gmane.org/gmane.comp.p.../670/focus=679
qui pointe vers cet article:
http://www.voidspace.org.uk/ironpyth...tensions.shtml

Si j'ai bien compris (j'explique lentement, pour éviter de me perdre) :

Il s'agit d'un Assembly (un package .NET) qui embarque un interpréteur
python classique (python25.dll, quoi).
On a donc la possibilité d'appeler à partir de .NET des fonction de
l'API python C: Il y a une conversion naturelle pour les types simples
du C (int, char*), et les PyObject* sont emballés dans un objet .NET qui
sert de 'proxy'.

Un exemple: l'assembly définit la fonction Import, qui appelle
naturellement la fonction C PyImport_ImportModule(char* name) (celle-ci:
http://docs.python.org/dev/c-api/uti...t_ImportModule ).
Elle renvoie un PyObject* (le module). Ce pointeur est emballé dans un
objet .NET.
La classe de cet objet définit plusieurs méthodes. Par exemple,
GetAttr(name), dont l'implémentation effectue un appel à la fonction C
PyObject_GetAttr. Ainsi on a accès à un membre de l'objet considéré.
Je suppose que la plupart des méthodes "abstraites" (celles-ci:
http://docs.python.org/dev/c-api/abstract.html ) sont accessibles de
cette manière.

Tout ceci permet d'utiliser un interpréteur PythonC classique à partir
de .NET, avec toutes ses extensions disponibles.

Maintenant, IronPython peut facilement utiliser ces objets:
(ce qui suit est du code IronPython)
class PythonObject:
def __init__(self, real):
self.real = real
def __getattr__(self, name):
return PythonObject(self.real.GetAttr(name))
# toutes les autres méthodes en __xxx___ sur le même modèle

Et l'objet qui vient de CPython est accessible de manière presque
transparente!

presque... ça ne marche pas à tous les coups:

- les objets CPython qui redéfinissent __getattr__ ne sont pas
correctement emballés.

- L'auteur a choisi de convertir (donc copier) les types simples, dès
qu'ils passent de IronPython à CPython. En particulier, si une fonction
modifie une liste passée en argument, IronPython n'y verra rien!

- pour les objets emballés (non convertis), les méthodes du genre
'isinstance' ne fonctionneront pas correctement. Idem pour les exceptions.

- Seuls les types basiques peuvent être passés à CPython. Par exemple,
il semble impossible de passer un 'file' IronPython à une fonction de
type cPickle.load, ce qui est pourtant utile
(http://docs.python.org/dev/library/p...ml#pickle.load ) : il
faudrait que CPython sache appeler une méthode .NET. Il est possible de
faire fonctionner ce genre de "callback", mais ce n'est pas implémenté.


Au total, cela ressemble assez à un mécanisme d'appels de fonctions à
distance (Remote Procedure Call), comme Pyro qui me semble assez abouti
(http://pyro.sourceforge.net/documentation.html ). ça marche pour les
types de base, mais il ne faut pas croire que tout est transparent.

Désolé d'avoir été si long... et j'espère n'avoir embrouillé personne
avec ma salade de pythons.

--
Amaury Forgeot d'Arc