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...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Amaury Forgeot d'Arc
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.python.dotnet/670/focusg9 qui pointe vers cet article: http://www.voidspace.org.uk/ironpython/cpython_extensions.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/utilities.html#PyImport_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/pickle.html#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
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.python.dotnet/670/focusg9
qui pointe vers cet article:
http://www.voidspace.org.uk/ironpython/cpython_extensions.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/utilities.html#PyImport_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/pickle.html#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.
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.python.dotnet/670/focusg9 qui pointe vers cet article: http://www.voidspace.org.uk/ironpython/cpython_extensions.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/utilities.html#PyImport_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/pickle.html#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
Méta-MCI \(MVP\)
Bonsoir !
C'est plutôt clair. Merci d'avoir passé du temps à résumer le fil des discussions.
Les limites sont presque les mêmes que lorsque je veux, par exemple, intégrer Python et JScript ou Ruby ; ce qui fait que j'ai une impression de déjà vu.
Finalement, j'ai bien fait de demander de l'aide, car mon anglais est vraiment trop insuffisant.
Merci encore.
@-salutations
Michel Claveau
Bonsoir !
C'est plutôt clair. Merci d'avoir passé du temps à résumer le fil des discussions.
Les limites sont presque les mêmes que lorsque je veux, par exemple, intégrer Python et JScript ou
Ruby ; ce qui fait que j'ai une impression de déjà vu.
Finalement, j'ai bien fait de demander de l'aide, car mon anglais est vraiment trop insuffisant.
C'est plutôt clair. Merci d'avoir passé du temps à résumer le fil des discussions.
Les limites sont presque les mêmes que lorsque je veux, par exemple, intégrer Python et JScript ou Ruby ; ce qui fait que j'ai une impression de déjà vu.
Finalement, j'ai bien fait de demander de l'aide, car mon anglais est vraiment trop insuffisant.
