Bonsoir,

j'ai le projet d'écrire un petit serveur distant dont le principe de
fonctionnement reposerait sur la connexion d'un interpréteur Python
interactif à une socket TCP.
Plusieurs idées d'implémentation me sont venues à l'esprit, mais pour le
moment rien de concret ne fonctionne.
La première idée consisterait à lancer une instance d'interpréteur
Python au début du script du serveur et à raccorder sa stdin, stdout et
stderr au socket. Il me semblait avoir aperçu un module qui permettait
d'instancier un interpréteur mais je ne retrouve pas l'info.
La deuxième idée consisterait à lancer un interpréteur via un popen2 ou
popen3 (si on veut utiliser stderr), ensuite relier les entrées/sorties
au socket avec certainement un ou deux threads pour assurer une
communication propre.
J'ai eu beau faire tous les essais possibles et imaginables, à la sauce
os.popen2 et os.open3, Popen, subprocess, ... rien ne fonctionne dans
mon Windows XP SP2.
J'ai bien noté que l'ordre de stdout, stdin, stderr n'était pas
positionné de la même manière suivant les modules et j'ai fais attention
à ne pas me mélanger les pinceaux.
Un stdout.readline() bloque, un stdin.write() semble fonctionner mais je
ne peux en vérifier la véracité.
Un petit essai avec la commande cmd.exe de Windows en lieu et place de
python.exe fonctionne parfaitement: je peux lancer une commande via
stdin et lire le résultat sur stdout, le résultat est conforme à ce qui
est attendu.
Avec le gestionnaire de taches Windows lors des essais avec
'C:\\Python25\\python.exe', j'ai noté qu'un nouveau process python.exe
était effectivement lancé, mais les fichiers sdtin et stdout se refusent
à recevoir et à envoyer les données.

Si quelqu'un a une idée pour m'aider à avancer, je suis preneur.


Merci d'avance pour votre aide,


Laurent

P.S.: j'ai trouvé plein de trucs sur Google, mais rien qui corresponde à
mes symptômes.

>
> Si quelqu'un a une idée pour m'aider à avancer, je suis preneur.
>
>
Peut être regarder ipython1
http://ipython.scipy.org/moin/IPython1
The IPython Engine exposes the capabilities of the IPython Core to
standard network connections.

Ca ressemble à ce que tu veux faire ?

>
> Si quelqu'un a une idée pour m'aider à avancer, je suis preneur.
>
>
Peut être regarder ipython1
http://ipython.scipy.org/moin/IPython1
The IPython Engine exposes the capabilities of the IPython Core to
standard network connections.

Ca ressemble à ce que tu veux faire ?

jean-marc pouchoulon a écrit :
>
>>
>> Si quelqu'un a une idée pour m'aider à avancer, je suis preneur.
>>
>>
> Peut être regarder ipython1
> http://ipython.scipy.org/moin/IPython1
> The IPython Engine exposes the capabilities of the IPython Core to
> standard network connections.
>
> Ca ressemble à ce que tu veux faire ?

Ca y ressemble.
J'aimerai quand même comprendre pourquoi je n'arrive pas à accéder à
stdin et stdout de l'interpreteur que je lance via 'popen'.

Je vais regarder IPython1 plus en détail.
Merci pour ton aide,


Laurent

jean-marc pouchoulon a écrit :
>
>>
>> Si quelqu'un a une idée pour m'aider à avancer, je suis preneur.
>>
>>
> Peut être regarder ipython1
> http://ipython.scipy.org/moin/IPython1
> The IPython Engine exposes the capabilities of the IPython Core to
> standard network connections.
>
> Ca ressemble à ce que tu veux faire ?

Ca y ressemble.
J'aimerai quand même comprendre pourquoi je n'arrive pas à accéder à
stdin et stdout de l'interpreteur que je lance via 'popen'.

Je vais regarder IPython1 plus en détail.
Merci pour ton aide,


Laurent

> Avec le gestionnaire de taches Windows lors des essais avec
> 'C:\\Python25\\python.exe', j'ai noté qu'un nouveau process python.exe
> était effectivement lancé, mais les fichiers sdtin et stdout se refusent
> à recevoir et à envoyer les données.
>
> Si quelqu'un a une idée pour m'aider à avancer, je suis preneur.
>
Un petit exemple serait plus parlant.

Nicolas

> Avec le gestionnaire de taches Windows lors des essais avec
> 'C:\\Python25\\python.exe', j'ai noté qu'un nouveau process python.exe
> était effectivement lancé, mais les fichiers sdtin et stdout se refusent
> à recevoir et à envoyer les données.
>
> Si quelqu'un a une idée pour m'aider à avancer, je suis preneur.
>
Un petit exemple serait plus parlant.

Nicolas

Cémoi a écrit :
> Bonsoir,
>
> j'ai le projet d'écrire un petit serveur distant dont le principe de
> fonctionnement reposerait sur la connexion d'un interpréteur Python
> interactif à une socket TCP.
> Plusieurs idées d'implémentation me sont venues à l'esprit, mais pour le
> moment rien de concret ne fonctionne.
> La première idée consisterait à lancer une instance d'interpréteur
> Python au début du script du serveur et à raccorder sa stdin, stdout et
> stderr au socket. Il me semblait avoir aperçu un module qui permettait
> d'instancier un interpréteur mais je ne retrouve pas l'info.
> La deuxième idée consisterait à lancer un interpréteur via un popen2 ou
> popen3 (si on veut utiliser stderr), ensuite relier les entrées/sorties
> au socket avec certainement un ou deux threads pour assurer une
> communication propre.
> J'ai eu beau faire tous les essais possibles et imaginables, à la sauce
> os.popen2 et os.open3, Popen, subprocess, ... rien ne fonctionne dans
> mon Windows XP SP2.
> J'ai bien noté que l'ordre de stdout, stdin, stderr n'était pas
> positionné de la même manière suivant les modules et j'ai fais attention
> à ne pas me mélanger les pinceaux.
> Un stdout.readline() bloque, un stdin.write() semble fonctionner mais je
> ne peux en vérifier la véracité.
> Un petit essai avec la commande cmd.exe de Windows en lieu et place de
> python.exe fonctionne parfaitement: je peux lancer une commande via
> stdin et lire le résultat sur stdout, le résultat est conforme à ce qui
> est attendu.
> Avec le gestionnaire de taches Windows lors des essais avec
> 'C:\\Python25\\python.exe', j'ai noté qu'un nouveau process python.exe
> était effectivement lancé, mais les fichiers sdtin et stdout se refusent
> à recevoir et à envoyer les données.
>
> Si quelqu'un a une idée pour m'aider à avancer, je suis preneur.
>
>
> Merci d'avance pour votre aide,
>
>
> Laurent
>
> P.S.: j'ai trouvé plein de trucs sur Google, mais rien qui corresponde à
> mes symptômes.

Q? Est-ce que tu as bien donné l'option -i au process Python ?

-i : inspect interactively after running script, (also
PYTHONINSPECT=x) and force prompts, even if stdin does not appear to be
a terminal


Au cas où...

Cémoi a écrit :
> Bonsoir,
>
> j'ai le projet d'écrire un petit serveur distant dont le principe de
> fonctionnement reposerait sur la connexion d'un interpréteur Python
> interactif à une socket TCP.
> Plusieurs idées d'implémentation me sont venues à l'esprit, mais pour le
> moment rien de concret ne fonctionne.
> La première idée consisterait à lancer une instance d'interpréteur
> Python au début du script du serveur et à raccorder sa stdin, stdout et
> stderr au socket. Il me semblait avoir aperçu un module qui permettait
> d'instancier un interpréteur mais je ne retrouve pas l'info.
> La deuxième idée consisterait à lancer un interpréteur via un popen2 ou
> popen3 (si on veut utiliser stderr), ensuite relier les entrées/sorties
> au socket avec certainement un ou deux threads pour assurer une
> communication propre.
> J'ai eu beau faire tous les essais possibles et imaginables, à la sauce
> os.popen2 et os.open3, Popen, subprocess, ... rien ne fonctionne dans
> mon Windows XP SP2.
> J'ai bien noté que l'ordre de stdout, stdin, stderr n'était pas
> positionné de la même manière suivant les modules et j'ai fais attention
> à ne pas me mélanger les pinceaux.
> Un stdout.readline() bloque, un stdin.write() semble fonctionner mais je
> ne peux en vérifier la véracité.
> Un petit essai avec la commande cmd.exe de Windows en lieu et place de
> python.exe fonctionne parfaitement: je peux lancer une commande via
> stdin et lire le résultat sur stdout, le résultat est conforme à ce qui
> est attendu.
> Avec le gestionnaire de taches Windows lors des essais avec
> 'C:\\Python25\\python.exe', j'ai noté qu'un nouveau process python.exe
> était effectivement lancé, mais les fichiers sdtin et stdout se refusent
> à recevoir et à envoyer les données.
>
> Si quelqu'un a une idée pour m'aider à avancer, je suis preneur.
>
>
> Merci d'avance pour votre aide,
>
>
> Laurent
>
> P.S.: j'ai trouvé plein de trucs sur Google, mais rien qui corresponde à
> mes symptômes.

Q? Est-ce que tu as bien donné l'option -i au process Python ?

-i : inspect interactively after running script, (also
PYTHONINSPECT=x) and force prompts, even if stdin does not appear to be
a terminal


Au cas où...

>> Laurent
>>
>> P.S.: j'ai trouvé plein de trucs sur Google, mais rien qui corresponde à
>> mes symptômes.
>
> Q? Est-ce que tu as bien donné l'option -i au process Python ?
>
> -i : inspect interactively after running script, (also
> PYTHONINSPECT=x) and force prompts, even if stdin does not appear to be
> a terminal
>
>
> Au cas où...

Ben, il s'avère que ce n'est pas "au cas ou' mais obligatoire pour que
ça fonctionne. Bien vu, Laurent !
J'avais fait l'essai, mais j'avais dû cumuler une autre erreur au même
moment qui m'a laissé à penser que ce mode d'inspection interactif
n'était pas adapté à la situation.
Pour résumer, voilà le code sous Windows XP SP2 / Python 2.5.1 qui me
permet d'utiliser trois objets de type fichier (input output et error)
reliés à un interpréteur Python:

>>> import os
>>> pyin, pyout, pyerr = os.popen3('C:\\Python25\\python.exe -i')
>>> pyerr.readline()
'Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32\n'
>>> pyerr.readline()
'Type "", "copyright", "credits" or "license" for more information.\n'
>>> pyin.write('vars()\n')
>>> pyout.readline()
"{'__builtins__': <module '__builtin__' (built-in)>, '__name__':
'__main__', '__
doc__': None}\n"

J'ai noté en faisant des essais sous Solaris qu'un pyin.flush() était
obligatoire après chaque pyin.write(), que j'utilise l'option -u ou non
au lancement de l'interpréteur. Sous Windows, je vais l'utiliser
également, ça ne mange pas de pain.
Il faut noter que toute tentative de lecture soit sur pyout soit sur
pyerr est bloquante si la sortie est vide, et que dans les autres cas on
ne récupère jamais le prompt.
Ne pas oublier de terminer les commandes que l'on envoie à
l'interpréteur par un '\n'.
Si je ne dis pas de bêtise, une instruction pyint.close() termine
l'interpréteur proprement.

Les autres approches avec Popen et subprocess devraient également
fonctionner, mais je n'ai pas eu le temps de ressayer.

Bon, il ne me reste plus qu'à jouer avec pyin, pyout et pyerr en les
raccordant à une socket.
Le module asynchat me sera peut-être utile, pour peu qu'il ne soit pas
trop lourd à mettre en oeuvre.
Vu le type d'implémentation choisie, je pense que je vais lancer
l'interpréteur avec un script qui va charger tous les modules
nécessaires et effectuer les initialisations adéquates pour assurer le
service dont j'ai besoin (in fine, ça devrait me donner un serveur
distant interactif fort sympathique). C'est peut-être pas demain la
veille que j'aurai la complétion automatique qui fonctionnera, mais
l'espoir fait vivre.

Pour répondre à Jean-Marc, j'ai commencé à regarder IPython1 qui doit
permettre de répondre intégralement à mes attentes, mais ça me parait un
peu complexe et pas forcément bien documenté.

Merci pour vos réponses et suggestions,

Laurent

>> Laurent
>>
>> P.S.: j'ai trouvé plein de trucs sur Google, mais rien qui corresponde à
>> mes symptômes.
>
> Q? Est-ce que tu as bien donné l'option -i au process Python ?
>
> -i : inspect interactively after running script, (also
> PYTHONINSPECT=x) and force prompts, even if stdin does not appear to be
> a terminal
>
>
> Au cas où...

Ben, il s'avère que ce n'est pas "au cas ou' mais obligatoire pour que
ça fonctionne. Bien vu, Laurent !
J'avais fait l'essai, mais j'avais dû cumuler une autre erreur au même
moment qui m'a laissé à penser que ce mode d'inspection interactif
n'était pas adapté à la situation.
Pour résumer, voilà le code sous Windows XP SP2 / Python 2.5.1 qui me
permet d'utiliser trois objets de type fichier (input output et error)
reliés à un interpréteur Python:

>>> import os
>>> pyin, pyout, pyerr = os.popen3('C:\\Python25\\python.exe -i')
>>> pyerr.readline()
'Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32\n'
>>> pyerr.readline()
'Type "", "copyright", "credits" or "license" for more information.\n'
>>> pyin.write('vars()\n')
>>> pyout.readline()
"{'__builtins__': <module '__builtin__' (built-in)>, '__name__':
'__main__', '__
doc__': None}\n"

J'ai noté en faisant des essais sous Solaris qu'un pyin.flush() était
obligatoire après chaque pyin.write(), que j'utilise l'option -u ou non
au lancement de l'interpréteur. Sous Windows, je vais l'utiliser
également, ça ne mange pas de pain.
Il faut noter que toute tentative de lecture soit sur pyout soit sur
pyerr est bloquante si la sortie est vide, et que dans les autres cas on
ne récupère jamais le prompt.
Ne pas oublier de terminer les commandes que l'on envoie à
l'interpréteur par un '\n'.
Si je ne dis pas de bêtise, une instruction pyint.close() termine
l'interpréteur proprement.

Les autres approches avec Popen et subprocess devraient également
fonctionner, mais je n'ai pas eu le temps de ressayer.

Bon, il ne me reste plus qu'à jouer avec pyin, pyout et pyerr en les
raccordant à une socket.
Le module asynchat me sera peut-être utile, pour peu qu'il ne soit pas
trop lourd à mettre en oeuvre.
Vu le type d'implémentation choisie, je pense que je vais lancer
l'interpréteur avec un script qui va charger tous les modules
nécessaires et effectuer les initialisations adéquates pour assurer le
service dont j'ai besoin (in fine, ça devrait me donner un serveur
distant interactif fort sympathique). C'est peut-être pas demain la
veille que j'aurai la complétion automatique qui fonctionnera, mais
l'espoir fait vivre.

Pour répondre à Jean-Marc, j'ai commencé à regarder IPython1 qui doit
permettre de répondre intégralement à mes attentes, mais ça me parait un
peu complexe et pas forcément bien documenté.

Merci pour vos réponses et suggestions,

Laurent