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 ?
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
NicolasP
Avec le gestionnaire de taches Windows lors des essais avec 'C:Python25python.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.
Avec le gestionnaire de taches Windows lors des essais avec 'C:Python25python.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
Laurent Pointal
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:Python25python.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ù...
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
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:Python25python.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
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:Python25python.exe -i') pyerr.readline() 'Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32n'
pyerr.readline() 'Type "help", "copyright", "credits" or "license" for more information.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
win32n'
pyerr.readline()
'Type "help", "copyright", "credits" or "license" for more information.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é.
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:Python25python.exe -i') pyerr.readline() 'Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32n'
pyerr.readline() 'Type "help", "copyright", "credits" or "license" for more information.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é.
