Utilisation subprocess et données entrée

Bonjour à tous,
J'ai commencé à coder en python en 2024 (une bonne résolution n'est-ce pas ?) pour un projet professionnel et je suis actuellement bloqué avec l'utilisation de la fonction subprocess.
En effet, je dois exécuter un script python (écrit en CPython avec les packages CPython classiques : numpy, scipy...) dans un environnement qui ne supporte pas CPython. Pas de problème, j'ai une astuce : subprocess.
En effet, comme vous le savez cette fonction permet d'exécuter un code avec une version de python spécifiée par exemple. Voici juste après mon code :

Code:

---

1 2 3 4 5

import os import subprocess os.chdir(r "Mon_emplacement_de_code") Python312 = r "C:\Users...\AppData\Local\Programmes\Python\Python312\python.exe" subprocess.call([Python312,'pyNukiyama.py'])

---

Avec ce code je peux exécuter mon script pyNukiyama.py dans mon environnement qui ne supporte pas ce dernier code avec python 3.12 installé sur l'ordinateur. Super, ça marche !
Cependant, j'ai maintenant besoin d'interagir avec ce script pyNukiyama.py pour modifier les entrées utilisées dans ce dernier script (en gros, effectuer une boucle avec les valeurs envoyées dans pyNukiyama.py et récupérer les valeurs de sortie.
D'où ma question : comment faire ?
Peut-être, modifier le script pyNukiyama.py avant de lancer le sous-processus avec ? Ou bien, ne pas utiliser un script sauvegardé mais directement le code dans le sous-processus (pyNukiyama ne contient que 10 lignes...) ? Une autre idée ?

Merci pour votre aide !

Bonne journée !
Pierre

Bonjour

Citation:

---

Envoyé par PierreLCV

(une bonne résolution n'est-ce pas ?)

---

Pas certain. Une "bonne résolution" implique souvent un sacrifice (arrêter de fumer, boire, courrir les filles). Si apprendre Python te semble être un sacrifice je ne suis pas certain que tu sois dans la bonne voie. D'autant plus que les "bonnes résolutions" en général ne traversent pas le premier mois.
Mais trêve de philosophie...

Citation:

---

Envoyé par PierreLCV

Cependant, j'ai maintenant besoin d'interagir avec ce script pyNukiyama.py pour modifier les entrées utilisées dans ce dernier script (en gros, effectuer une boucle avec les valeurs envoyées dans pyNukiyama.py et récupérer les valeurs de sortie.
D'où ma question : comment faire ?
Peut-être, modifier le script pyNukiyama.py avant de lancer le sous-processus avec ? Ou bien, ne pas utiliser un script sauvegardé mais directement le code dans le sous-processus (pyNukiyama ne contient que 10 lignes...) ? Une autre idée ?

---

Si j'ai bien suivi: le script pyNukiyama.py attend des entrées via input() et tu voudrais que ces entrées lui soient envoyées automatiquement.
Il te faut alors utiliser la technologie des pipes (n'oublions pas que Python a été écrit au départ dans et pour Unix donc lui est implicitement lié).
Si tu ne connais pas cette technique (issue d'Unix), elle consiste à remplacer le clavier utilisé à l'input par un flux de datas passé en entrée du programme et transmis par un pipe (un tube de communication)

Exemple: voici un petit shell assez simple qui lit 2 valeurs au clavier et qui affiche la somme des deux

Code:

---

1 2 3 4 5

#!/bin/bash   read a read b echo $(($a+$b))

---

Et voici une possibilité de l'appeler via Python en lui passant les valeurs directement: subprocess.run("./script.sh", input=b"2\n3").
Tu noteras la simulation du <return> censé séparer les deux valeurs via le '\n".

Après ce n'est pas la seule façon. Pour des entrées plus complexes tu peux passer par subprocess.communicate, jouer avec stdin et stdout etc.

Bonjour,

J'avoue ne pas tout comprendre, jamais eu ce genre de situation à gérer, mais je vois quelques possibilités,

• Passer des arguments en ligne de commande au script pyNukiyama.py (ce qui demande à réécrire le script pour gérer ces arguments)
• Utiliser subprocess.Popen pour interagir avec stdin, stdout et stderr

Citation:

---

je dois exécuter un script python (écrit en CPython avec les packages CPython classiques : numpy, scipy...) dans un environnement qui ne supporte pas CPython.

---

Cette phrase me perturbe :?

salut,

pyNukiyama.py c'est du Python pas du CPython qui est du C et qui, après compilation, a une extension .so ou .dll.

Pourquoi ne pas importer pyNukiyama et interagir avec ce code tout simplement, surtout si tu peux le modifier ?

Cher Sve@r, fred1599 & VinsS,
Tout d'abord, merci beaucoup pour votre retour rapide ! Cher Sve@r, on pourrait filer ta remarque philosophique en rappelant que l'on a rien sans efforts :). Mais laissons ce sujet de côté...
Pour vous donner davantage de contexte. J'utilise un logiciel de thermique (Ansys) qui attends certaines conditions aux limites pour résoudre le problème par FEA. Pour définir ces conditions aux limites, j'ai besoin d'un code pyNukiyama qui, à partir de certaines entrées (Vitesse Fluide, Pression et Température), va me renvoyer ces fameuses conditions aux limites que Ansys attends pour résoudre.
Le problème étant que Ansys ne peut pas utiliser le code pyNukiyama car, d'aprés ce que j'ai compris Ansys utilise IronPython qui n'est pas compatible avec certains modules du style numpy, scipy etc... utilisés dans mon code pyNukiyama. D'où le besoin d'utiliser subprocess pour pouvoir quand même lancer pyNukiyama depuis Ansys. Mais, je dois pouvoir spécifier mes entrées (V,P,T) pour pouvoir faire tourner pyNukiyama. Donc la question, c'est comment depuis mon API IronPython je peux à l'aide de subprocess faire tourner pyNukiyama.py avec un triplet (V,P,T) que je précise via une boucle dans mon API Ansys par exemple.
- Pour les pipes, je ne suis pas sûr de comprendre comment faire cela et si c'est adapté à ma situation. Je pense que l'idée de fred1599 spécifiant d'utiliser stdin rejoint cette idée de pipe, mais peut-être serez vous en mesure de me dire avec ces nouveaux élèments si cela vous semble possible...
- l'idée d'utiliser des arguments que je spécifie dans mon appel à la fonction subprocess est intéressante mais j'avoue ne pas trop savoir comment faire...
- enfin VinsS, comme tu l'as sans doute mieux compris désormais, je ne peux hélas pas importer pyNukiyama dans mon logiciel (et donc pas non plus interagir avec), je suis astreint à le lancer dans subprocess qui me bloque l'interaction...

Merci de votre aide,
Cordialement,
Pierre

Citation:

---

Envoyé par PierreLCV

- Pour les pipes, je ne suis pas sûr de comprendre comment faire cela et si c'est adapté à ma situation. Je pense que l'idée de fred1599 spécifiant d'utiliser stdin rejoint cette idée de pipe, mais peut-être serez vous en mesure de me dire avec ces nouveaux élèments si cela vous semble possible...
- l'idée d'utiliser des arguments que je spécifie dans mon appel à la fonction subprocess est intéressante mais j'avoue ne pas trop savoir comment faire...
- enfin VinsS, comme tu l'as sans doute mieux compris désormais, je ne peux hélas pas importer pyNukiyama dans mon logiciel (et donc pas non plus interagir avec), je suis astreint à le lancer dans subprocess qui me bloque l'interaction...

---

La bonne nouvelle est que pour faire communiquer du python sous IronPython avec du Python sous CPython, faire communiquer 2 processus entre eux est une solution jouable.

Le soucis est qu'à la base, ça n'a rien à voir avec Python: passer des arguments à un process qu'on lance la communication via des PIPEs sont des mécanismes systèmes. Python ne fait que donner la possibilité au programmeur python d'utiliser ces mécanismes mais si on ne sait pas ce qu'ils sont, ni les messages à échanger, il y a un peu d'apprentissage à faire.

Ceci dit, échanger des informations via des fichiers sera peut être plus simple (si ça peut fonctionner avec de simples fichiers).

- W

Cher Wiztricks,
Je ne pas sûr de comprendre ton message... Ce n'est pas très grave, j'ai réussi à avancer un peu en utilisant l'option subprocess.popen. Voici mes codes:
le code "principal" que je peux exécuter dans mon environnement dégradé :

Code:

---

1 2 3 4 5 6 7

Vwater = 4 Pwater = 10 Twater = 120   p=subprocess.Popen("appel_nukiyama.py",stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,shell=True) out,err = p.communicate(input=f"{Vwater}, {Pwater}, {Twater}".encode()) result = out.decode()

---

Et le appel_nukiyama.py

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

import pyNukiyama   Vwater, Pwater, Twater = input("").split(",",3)   Tmin=10 Tmax=350   nuki = pyNukiyama.pyNukiyama("s", 0.021, 0, 0, 0, 0, 0, 0, 0.021, float(Twater), float(Pwater), float(Vwater), Tmin, Tmax) nuki.waterParameters() nuki.siederTate() nuki.berglesRohsenhow() nuki.CHF()     print(f"{nuki.tchf}]") print(f"{nuki.wchf}]") print(nuki.Tw_cut) print(nuki.hTot_cut)

---

Cela fonctionne pas trop mal pour le moment. Le seul problème c'est qu'avec ces deux codes je récupère les données renvoyées par les 4 print de appel_nukiyama.py au format "string" donc c'est pas super facile de remettre les données au bon format dans le code principal...

Merci de votre aide,
Cordialement
Pierre

Citation:

---

Envoyé par PierreLCV

Je ne pas sûr de comprendre ton message...

---

En fait, il te dit juste que la technologie de communication inter-processus est une technologie assez courante (tous les OS la possèdent) donc elle s'apprend "à part" (pas forcément dans Python) mais il te faut l'apprendre si tu veux bien la comprendre et l'utiliser.
Et ensuite Python t'offre une porte d'entrée dans cette techno.

Citation:

---

Envoyé par PierreLCV

Voici mes codes:

---

Essaye d'aérer un peu. Un espace après la virgule (comme en grammaire) ça ne coûte rien et ça aide à lire (relire) le code.
p=subprocess.Popen("appel_nukiyama.py", stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)...

Citation:

---

Envoyé par PierreLCV

Cela fonctionne pas trop mal pour le moment. Le seul problème c'est qu'avec ces deux codes je récupère les données renvoyées par les 4 print de appel_nukiyama.py au format "string" donc c'est pas super facile de remettre les données au bon format dans le code principal...

---

Tu peux utiliser les fonctions natives Python (ex int("123") te donne un int valant 123, float("123") te donne un float valant 123.0, etc)

@PierreLCV,

J'ai du mal :D Mais on va y arriver, j'aime bien quand les choses sont clairement définis, quitte à être bête dans mes questionnements.

Déjà sujet à ma réponse précédente, je voyais quelque chose comme cela

Code:

---

1 2 3 4 5 6 7

process = subprocess.Popen( [Python312, 'pyNukiyama.py'], stdin=subprocess.PIPE, stdout=subprocess.PIPE )   stdout, stderr = process.communicate(input='vos_entrees')

---

Cette méthode est utile pour automatiser les interactions avec des scripts qui attendent des entrées utilisateur ou pour tester des scripts de manière programmée.

Citation:

---

l'idée d'utiliser des arguments que je spécifie dans mon appel à la fonction subprocess est intéressante mais j'avoue ne pas trop savoir comment faire...

---

Pour être assez concis, tu dois modifier ton code pyNukiyama.py pour qu'il accepte des arguments (par ex. avec sys.argv) et exécuter pyNukiyama.py avec ses arguments comme cela,

Code:

---

subprocess.call([Python312, 'pyNukiyama.py', 'arg1', 'arg2'])

---

----------

Tu utilises IronPython, si je comprend bien, ça ne s'exécute pas comme un script python standard, on peut connaître le contenu de ce script ? Il n'y a que du python, du .NET ?

Trés chers fred1599 & Sve@r,
Tout d'abord, merci beaucoup pour vos réponses !
Il s'avére que Ansys a récemment incorporé CPython en version beta dans le logiciel que j'utilise. J'ai donc à ma disposition IronPython (le mode par défaut) et CPython en version beta (et donc non supporté).
En me mettant en "mode" CPython beta, je peux executer mon code pyNukiyama directement sans passer par subprocess. PROBLEME : Pour poser mon probléme (ie définir les conditions aux limites) je dois utiliser par la suite une fonction Quantity qui semble fonctionner que avec IronPython... Argh quelle deception :calim2:
Me voilà donc obligé de rester en IronPython, ce qui n'est pas forcément une mauvaise chose et m'évite de travailler avec des versions BETA.
Concernant ta solution fred1599 qui est je pense pertinente, on est d'accord que subprocess.Popen et subprocess.call sont deux solutions différentes ? Je vais creuser ces deux voies.
Je pense effet utiliser les fonctions natives de Python pour récupérer les valeurs dans les chaines de caractéres... ca va être du sport !

Merci de votre aide,
Pierre

On peut voir cette fonction Quantité ?
Il n'y a pas un moyen de là réécrire en pur python ? Que fait cette fonction ?

Édit : oui call et popen pour ton cas sont même 2 paradigmes différents. 🙂

Cher fred1599,
Merci pour ton retour trés rapide !
Alors, j'ai essayé ta solution avec popen, voici le code:

Code:

---

1 2 3 4 5 6 7

import os import subprocess os.chdir(r"C:\Users\...\Documents\Bac à sable\pyNukiyama") Python312 = r"C:\Users\...\AppData\Local\Programs\Python\Python312\python.exe"   process = subprocess.Popen([Python312,'appel_nukiyama.py'], stdin=subprocess.PIPE, stdout=subprocess.PIPE) out,err = process.communicate(input=f"{Vwater}, {Pwater}, {Twater}".encode())

---

En l'executant avec CPython (beta) ça marche mais pas avec IronPython qui me renvoi "invalid syntax"... le lourd !
Je vais peut-être essayer avec subprocess.call désormais...
Alors, la fonction Quantity est une fonction un peu spécifique à Ansys Mechanical je pense et qui permet d'avoir dans un même objet la valeur numérique ainsi que la dimension associée à cette dernière. C'est je pense une fonction trés simple qui prend deux arguments une valeur numérique et son unité, ex : Quantity("10 [C]"). J'ai hélas besoin de cette fonction pour poser mon problème...

Merci encore !

Pourtant IronPython a subprocess dans sa doc, c'est bizarre cette erreur de syntaxe.

Et je vois pas d'erreur dans tes lignes de code...

EDIT: Peux-tu donner l'erreur entière ?

Cher Fred,
Merci pour ta vérification... en effet, cette erreur est bizarre...
Voici une capture d'écran du code éxécuté en IronPython avec l'erreur "invalid syntax" et le même code executé en CPython sans problème...
Pièce jointe 649693
Je ne sais pas trop quoi faire face à cela...

est-ce que ironpython n'exécuterait pas du python 2.x ? Si c'est le cas tu devrais écrire print err et non print(err)

Alors oui c'est possible IronPython utilise du Python 2 mais hélas l'erreur de syntaxe apparait sans le print(err)... il doit y avoir une faute ailleurs...

Tu devrais traiter ligne par ligne sur ton interpréteur pour voir où est provoquer cette erreur de syntaxe

EDIT : Je pense peut-être au format de ton répertoire bac à sable (espace et accent)

Alors j'ai vérifié ligne par ligne le code suivant avec l'environnement IronPython

Code:

---

1 2 3 4 5 6 7

import os import subprocess os.chdir(r"C:\Users\...\Documents\Bac à sable\pyNukiyama") Python312 = r"C:\Users\...\AppData\Local\Programs\Python\Python312\python.exe"   process = subprocess.Popen([Python312,'appel_nukiyama.py'], stdin=subprocess.PIPE, stdout=subprocess.PIPE) out,err = process.communicate(input=f"{Vwater}, {Pwater}, {Twater}".encode())

---

Il apparait que tout va bien (tout du moins je n'ai pas d'erreurs) si je retire la dernière ligne. Mais alors une invite de commande s'ouvre a partir de Python312 et demeure en standby (attendant) sans doute les données d'entrées... Si je réactive la dernière ligne, c'est là que le problème de syntaxe apparait... Ce serait donc la dernière ligne qui pose problème... Je vais creuser cela demain !

Merci encore de votre aide
Pierre

Citation:

---

Si je réactive la dernière ligne, c'est là que le problème de syntaxe apparait

---

Peut-être regarder du côté du paramètre timeout de Popen.

Une question que l'on a pas évoqué: on ne peut pas réécrire le code de ton script pyNukiyama.py sans utiliser les librairies non compatibles IronPython? (comme on ne sait toujours pas son code et sa complexité)

Citation:

---

Envoyé par PierreLCV

Ce serait donc la dernière ligne qui pose problème... Je vais creuser cela demain !

---

La dernière version d'IronPython est compatible 3.4. (mais on ne sait pas quelle version vous utilisez).
Elle ne connait certainement pas les f-strings.

Par ailleurs s'il ne faut passer que 3 paramètres puis récupérer la sortie, subprocess.check_output devrait suffire (on passe les données dans les arguments d'appel).

- W

Chers fred1599, umfred & wiztricks,
Merci beaucoup pour vos retours !
Je vais essayer de fouiller dans la documentation pour voir si je peux connaitre la version de IronPython utilisée... Pourquoi pas utiliser subprocess.check_output en effet...
Je vais continuer à travailler sur cela aujourd'hui et revenir vers vous.

Cordialement
Pierre

Bonjour,

Citation:

---

Je vais essayer de fouiller dans la documentation pour voir si je peux connaitre la version de IronPython utilisée

---

Pourquoi ? On peut tout simplement pas exécuter l'interpréteur ipython pour connaître sa version ?

Cher fred1599,
Une petite vérification de la version utilisée me renvoie :

Code:

---

1 2 3 4 5

>>> import sys >>> sys.version '2.7.4 (IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.42000 (64-bit))'

---

C'est donc bien du Python 2.x. Je vais voir si les f-strings sont la cause du problème...

Merci beaucoup !
Pierre

Citation:

---

Envoyé par PierreLCV

C'est donc bien du Python 2.x. Je vais voir si les f-strings sont la cause du problème...

---

Ca risque fortement de l'etre car les f-strings (ainsi que la méthode str.format) n'existent pas sous P2...8-)

Chers Sve@r, fred1599, wiztricks et umfred,
Aprés pas mal d'essais, il apparait finalement que j'ai réussi à résoudre le problème de la fonction Quantity qui n'était pas disponible sur CPython... Donc plus besoin d'utiliser IronPython et plus besoin d'utiliser Subprocess ! Je vous avoue être assez soulagé car c'était assez compliqué...
Quoi qu'il en soit, MERCI BEAUCOUP de votre aide, je n'en attendais pas tant ! Je pense que l'on peut arrêter ici cette conversation en espérant que la CPython (beta) soit suffisamment stable à l'usage...
En parlant de stabilité, il s'avére que j'ai justement réalisé un script pour une utilisation paralléle à celle présentée ici et ce dernier est instable... Je m'en vais donc poster un nouveau sujet, au plaisir de vous retrouver sur ce nouveau problème...

Trés cordialement,
Pierre
MERCI ENCORE !